Claves del Vocabulario en System Design

Los términos más importantes de System Design

Tiempo estimado de lectura: 7 min

• Escalabilidad: crecer sin romperse.
• Latency y Throughput: impactan la experiencia del usuario.
• CAP Theorem: elige sabiamente entre consistencia y disponibilidad.
• Caching: clave para reducir la latencia.
• Observabilidad: mide y controla la eficacia del sistema.

Tabla de contenidos

• Escalabilidad (Scale Up vs Scale Out)
• Latency y Throughput
• Availability y Réplica
• CAP Theorem
• ACID vs BASE
• Sharding (Particionamiento)
• Caching e Invalidación
• Load Balancer
• Message Queues y Backpressure
• Idempotency
• Observabilidad: métricas, logs y trazas
• Rate Limiting y Protección de Costos
• Consistencia de Datos entre sistemas
• Automatización y Orquestación
• Cómo usar este vocabulario como criterio técnico
• Cierre: palabras que cambian decisiones

Escalabilidad (Scale Up vs Scale Out)

Escalabilidad es la capacidad de tu sistema para crecer sin romperse.

• Scale up: añadir CPU/RAM a una máquina. Rápido, limitado.
• Scale out: añadir más instancias. Potente, pero requiere distribución de estado.

Decisión práctica: servicios sin estado → scale out. Bases de datos con mucho estado → planifica sharding y réplica.

Referencia: PostgreSQL

Latency y Throughput

• Latency: tiempo por petición (ms). Afecta UX.
• Throughput: operaciones por segundo. Afecta capacidad.

Trade-off real: batching aumenta throughput y empeora latency. Define SLAs y optimiza según la prioridad del endpoint.

Availability y Réplica

Disponibilidad = porcentaje de tiempo activo (nueves). Redundancia y réplica aumentan availability pero generan complejidad de consistencia y latencia de replicación.

CAP Theorem

En fallas de red solo puedes elegir dos: Consistencia, Disponibilidad o Tolerancia a particiones. No es dogma, es un mapa de decisiones. Lee la base: CAP theorem

ACID vs BASE

• ACID: transacciones seguras (SQL, p. ej. PostgreSQL).
• BASE: disponible y eventualmente consistente (NoSQL, p. ej. DynamoDB).

Elige según la criticidad del dato (pagos → ACID; analytics → BASE).

Sharding (Particionamiento)

Fragmentar datos para escalar horizontalmente. Riesgo real: hot shards. Elige la clave de partición con criterio (evita userId secuenciales, usa hashing o ranges balanceados).

Caching e Invalidación

Cachés (Redis, Memcached) son la palanca más efectiva contra latencia, pero la invalidación es la bestia difícil. Documenta y automatiza políticas TTL y cache-busting.

Load Balancer

Distribuye tráfico (Layer 4 vs Layer 7). No subestimes la lógica de sticky sessions o afinidad cuando usas sessions en memoria.

Message Queues y Backpressure

Kafka o RabbitMQ permiten desacoplar y absorber picos. Implementa DLQ (Dead Letter Queue) para errores repetidos y evita perder mensajes.

Idempotency

Si tu endpoint procesa pagos o crea recursos, hazlo idempotente. Necesitas idempotency keys y almacenamiento de intentos para evitar duplicados.

Observabilidad: métricas, logs y trazas

Sin observabilidad estás volando a ciegas. Usa Prometheus + tracing distribuido. Mide percentiles (p50, p95, p99), no promedios.

Rate Limiting y Protección de Costos

Controla uso por usuario/service. Hoy es crítico para APIs con coste por uso (p. ej. modelos de IA). Implementa límites y circuit breakers.

Consistencia de Datos entre sistemas (Eventual Consistency Patterns)

Cuando sincronizas bases de datos y stores (por ejemplo, SQL + vector DB para RAG), diseña reconciliadores y explica expectativas de latencia a producto.

Automatización y Orquestación (Workflows y Agentes)

En sistemas modernos trabajas con pipelines y agentes: orquestadores como n8n o herramientas internas organizan procesos complejos sin reescribir la lógica en cada microservicio.

Para equipos que construyen automations productivas y agentes de IA, Dominicode Labs ofrece plantillas y workflows listos para producción. Es útil si quieres pasar de prototipo a pipeline productivo con mejores prácticas en manejo de colas, rate limiting y observabilidad.

Cómo usar este vocabulario como criterio técnico

No memorices. Usa cada término para responder tres preguntas cuando diseñes:

1. ¿Cuál es el peor fallo posible? (partición, hot shard, pérdida de mensajes)
2. ¿Qué contrato de servicio necesito? (latency p95, availability)
3. ¿Cuál es el coste y cómo se controla? (GPUs, requests por token, storage)

Si tu respuesta no justifica la complejidad técnica, reduce alcance. MVPs necesitan simples decisiones: autenticación gestionada, base de datos relacional, caché selectivo. Escala cuando la métrica lo diga.

Cierre: palabras que cambian decisiones

Estas palabras no son jerga; son palancas. Domínalas y dejarás de reaccionar cuando algo falle: empezarás a diseñar con intención. El siguiente paso práctico es dibujar tu flujo de datos, marcar puntos de fallo y asignar un patrón a cada término: caché donde la latencia mata; cola donde el throughput supera la sincronía; réplica donde la disponibilidad vale cada centavo.

Si quieres ejemplos aplicados y workflows reproducibles que conecten estas decisiones con agentes y automatización real, revisa Dominicode Labs y sus plantillas para llevar un diseño teórico a producción sin perder el control.

FAQ

• ¿Qué es la escalabilidad en systems design?
• ¿Cuándo es mejor usar ACID en lugar de BASE?
• ¿Cómo se implementa el rate limiting?
• ¿Qué son los hot shards en sharding?
• ¿Cómo funciona el CAP Theorem?

La escalabilidad en systems design se refiere a la capacidad de un sistema para aumentar su capacidad y soporte sin comprometer su rendimiento. Se puede abordar mediante estrategias de Scale Up (mejora de hardware) o Scale Out (adición de más instancias).

Es recomendable utilizar ACID cuando se manejan transacciones críticas, como en el caso de pagos. BASE es más adecuado para aplicaciones que requieren alta disponibilidad y pueden tolerar una consistencia eventual, como analíticas.

El rate limiting se implementa controlando el número de solicitudes que un usuario o servicio puede hacer a un recurso en un periodo determinado. Se pueden usar mecanismos como tokens o circuit breakers para gestionar estos límites.

Los hot shards son puntos de partición de datos que reciben una carga desproporcionada de solicitudes o transacciones, lo que puede causar cuellos de botella. Es importante elegir una estrategia de particionamiento que evite esta situación.

El CAP Theorem establece que en condiciones de fallas de red, solo se puede garantizar la consistencia, disponibilidad o tolerancia a particiones, pero no las tres al mismo tiempo. Esto ayuda a guiar las decisiones de diseño de sistemas.