System Design
Integra problema, requisitos, comportamiento, dominio, datos, contratos, arquitectura, atributos de calidad, riesgos, evidencia, operación y evolución en un solo modelo mental.
System Design es el proceso de convertir un problema ambiguo en un sistema explicable, verificable, operable y evolutivo. El resultado no es un diagrama: es una cadena coherente de decisiones y evidencia.
problema y evidencia
→ stakeholders, actores y objetivos
→ alcance, restricciones y lenguaje
→ requisitos, reglas y criterios
→ procesos, escenarios y estados
→ dominio y datos
→ contratos y responsabilidades
→ componentes y despliegue
→ seguridad, capacidad y resiliencia
→ observabilidad y operación
→ decisiones, riesgos y POC
→ pruebas, trazabilidad y evoluciónCada paso reduce una clase distinta de incertidumbre. Saltar directamente a infraestructura deja sin resolver qué debe hacer el sistema y cómo sabremos que funciona.
Describe situación actual, evidencia, impacto y resultado esperado.
No empieces con “necesitamos una app”. Pregunta qué trabajo falla, quién lo experimenta y cómo se mide.
Distingue stakeholders, actores y sistemas externos. Identifica objetivos, responsabilidades, poder, conocimiento y conflicto.
Declara in scope, out of scope, dependencias y fuentes de verdad. Un sistema puede participar en un proceso sin ser dueño de todo.
Especifica requisitos funcionales, atributos de calidad, restricciones, supuestos y reglas verificables.
Modela procesos, escenarios nominales, alternativas, fallos, interacciones, estados y compensaciones.
Descubre identidad, invariantes, value objects, agregados, cardinalidad, integridad, historial, privacidad y concurrencia.
Asigna responsabilidades y define APIs, eventos, idempotencia, errores, ownership y compatibilidad.
Diseña timeouts, aislamiento, degradación, recuperación, observabilidad, SLOs, runbooks y capacidad.
Registra trade-offs, riesgos, POC, pruebas, trazabilidad, rollout, deprecación y documentación viva.
Recoge:
Resultado: una formulación del problema que puede refutarse o confirmarse.
Construye un mapa de intereses y resultados. Evita asumir que todos quieren lo mismo.
Define cambio esperado, beneficiarios y señales de éxito. La visión orienta; no sustituye requisitos.
Expresa responsabilidades y resultados, no pantallas. Define exclusiones y cómo se resuelven temporalmente.
Ubica usuarios, sistemas externos y canales. Toda dependencia introduce contrato, fallo, latencia y owner.
Construye glosario con términos, ejemplos, contraejemplos y diferencias importantes. Un término ambiguo produce reglas ambiguas.
Un requisito útil tiene:
Expresan decisiones del dominio. Deben tener owner, alcance, excepciones y ejemplos.
Usa escenarios:
fuente
→ estímulo
→ ambiente
→ elemento
→ respuesta
→ medidaOrdena por valor, riesgo, dependencia y aprendizaje. “Todo es prioritario” significa que no existe decisión.
Las historias organizan entrega; los criterios convierten expectativas en ejemplos verificables.
Describen cómo un actor alcanza un objetivo. Incluyen garantía mínima, éxito, alternativas y excepciones.
As-is revela realidad, handoffs y desperdicio. To-be propone un futuro operativo viable.
Muestran participantes, mensajes, orden, timeouts, asincronía y recuperación.
Hacen explícitas transiciones válidas, guards, efectos y estados inciertos. Evitan combinaciones contradictorias de booleanos.
Prioriza comportamiento e invariantes. No todo sustantivo es entidad ni toda tabla es concepto de dominio.
conceptual
→ significado del negocio
lógico
→ estructura e integridad
físico
→ implementación y accesoDecide:
Normalizar y desnormalizar son decisiones contextuales, no dogmas.
Asigna conocimiento, decisión y coordinación buscando alta cohesión y acoplamiento controlado.
Una API incluye semántica, autenticación, autorización, errores, idempotencia, paginación, límites, evolución y SLOs.
Un evento representa un hecho. Diseña identidad, versión, correlación, orden, duplicados, retención y consumidores.
Cada componente tiene responsabilidad y contratos claros. No dibujes archivos ni capas vacías como componentes conceptuales.
Quién usa el sistema y con cuáles sistemas colabora.
Aplicaciones, servicios, workers y almacenes ejecutables.
Módulos internos relevantes de un container.
Dónde corre cada cosa, cómo se comunica, qué se replica y cómo falla.
Una vista responde una pregunta y conserva un nivel de abstracción.
Parte de activos, amenazas y límites de confianza. Autenticar no sustituye autorizar. Minimiza datos y diseña retención, auditoría y respuesta.
Estima órdenes de magnitud, picos, almacenamiento, ancho de banda y crecimiento. Luego valida con benchmark o carga.
Diseña timeouts, retry budgets, backoff, idempotencia, circuit breakers, bulkheads, load shedding, fallback y reconciliación.
Define y prueba RTO, RPO, restore, failover y operación degradada.
Conecta logs, métricas y trazas con preguntas y acciones. Define SLIs, SLOs y alertas sobre impacto real.
Toda alternativa optimiza algo y sacrifica algo. Registra drivers, opciones, consecuencias y reversibilidad.
Sirven para estructurar comparación, no para fabricar certeza. Usa restricciones eliminatorias, evidencia y sensibilidad.
Formula eventos inciertos con causa, impacto, trigger, owner, respuesta y riesgo residual.
Una POC responde una pregunta con criterio de salida. No demuestra automáticamente preparación para producción.
objetivo
→ requisito
→ regla
→ escenario
→ diseño
→ implementación
→ prueba
→ señal operativaRecorre escenarios, contradicciones, fallos, calidad y operación con las audiencias correctas.
Selecciona niveles según riesgo y oráculo. Diseña testability, datos, ambientes y evidencia.
Analiza impacto, compatibilidad, migración, rollout, rollback y deprecación.
Mantiene fuente de verdad, owner, estado, fecha, relaciones y triggers de revisión.
¿Quién usa qué sistema?
→ Context diagram
¿Qué piezas ejecutables existen?
→ Container diagram
¿Qué módulos internos colaboran?
→ Component diagram
¿Qué mensajes ocurren y en qué orden?
→ Sequence diagram
¿Qué caminos y decisiones sigue un proceso?
→ Activity diagram
¿Qué transiciones admite una entidad?
→ State diagram
¿Qué datos persistentes y cardinalidades existen?
→ ERD
¿Qué clases y responsabilidades estructurales importan?
→ Class diagram
¿Por qué se eligió una alternativa?
→ ADRNo uses un diagrama porque “toca”; úsalo porque reduce una incertidumbre concreta.
Un diseño coherente debe permitir estas comprobaciones:
No diseñes todas las partes al mismo nivel. Profundiza donde coinciden:
alto impacto
+ alta incertidumbre
+ baja reversibilidad
+ detección difícilUna pantalla simple puede necesitar poco modelado. Una reserva concurrente, aislamiento multi-tenant o compensación financiera exige mucha más profundidad.
La solución más simple aceptable:
“Simple” no significa omitir seguridad, recuperación o consistencia esenciales.
Aprende a formular problema, actores, objetivos, alcance, requisitos, reglas, historias y casos.
Conecta procesos, estados, dominio, datos, contratos, componentes, seguridad y capacidad.
Profundiza en fallos distribuidos, operación, trade-offs, riesgos, experimentos, trazabilidad y evolución.
No memorices símbolos aislados. Toma un sistema real y recorre la cadena de principio a fin.
Diseña una transferencia de inventario entre sucursales:
System Design no es adivinar la infraestructura perfecta. Es sostener una conversación rigurosa entre necesidad, comportamiento, información, responsabilidad, calidad, fallo y evidencia.
Un diseño 1000/10 no es el más complejo ni el que tiene más diagramas. Es el que permite explicar:
Vuelve a Qué es System Design cuando necesites recordar el propósito; usa Diseño de un sistema completo para practicar la integración y Antipatrones de System Design para auditar decisiones antes de añadir complejidad.