System Design
Qué es System Design
Explica System Design como un proceso para reducir incertidumbre y conectar problema, comportamiento, datos, responsabilidades, riesgos y validación.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica System Design como un proceso para reducir incertidumbre y conectar problema, comportamiento, datos, responsabilidades, riesgos y validación.
System Design no consiste en dibujar cajas ni escoger tecnologías. Consiste en reducir incertidumbre antes y durante la construcción de un sistema, conectando problema, comportamiento, datos, responsabilidades, riesgos y criterios de validación.
System Design es el proceso de transformar una necesidad incierta en una representación suficientemente clara para construir, revisar, evolucionar y operar una solución.
Su recorrido puede verse así:
problema observado
→ objetivos y restricciones
→ comportamiento esperado
→ dominio y datos
→ responsabilidades y contratos
→ decisiones y trade-offs
→ validación y evoluciónEl resultado no es un único documento. Es un conjunto coherente de decisiones y modelos que permiten responder preguntas concretas.
Construir software sin diseño suficiente suele producir:
System Design reduce ese riesgo haciendo visibles las decisiones antes de que queden enterradas en código, infraestructura y datos reales.
Piensa en el diseño como un puente entre intención y ejecución:
negocio y usuarios
↓
necesidades y reglas
↓
modelos y contratos
↓
software e infraestructura
↓
resultados observablesCada nivel debe conservar trazabilidad con el anterior. Una API sin requisito es una decisión sin propósito. Un requisito sin evidencia es una suposición disfrazada. Un diagrama sin audiencia es decoración.
Busca comprender el problema, el contexto y las necesidades. Produce evidencia, preguntas, reglas y objetivos.
Convierte esa comprensión en comportamiento, modelos, límites, contratos, responsabilidades y decisiones verificables.
Organiza la estructura técnica de la solución y las dependencias de largo plazo. Se enfoca especialmente en cualidades, evolución y restricciones estructurales.
Materializa las decisiones en código, infraestructura, configuración y datos.
La separación no es rígida. En proyectos reales se itera:
analizar
→ diseñar
→ prototipar
→ aprender
→ corregir análisis y diseñoUn diseño útil debe aclarar, según el sistema:
No existe una lista obligatoria. Algunos artefactos responden preguntas distintas:
Un artefacto solo es útil si mejora una decisión, una conversación o una validación.
Diseñar más no siempre significa diseñar mejor.
Un sistema pequeño puede necesitar:
Un sistema regulado o distribuido puede necesitar trazabilidad completa, amenazas, recuperación, contratos versionados y escenarios de fallo.
La profundidad depende de:
No todas las decisiones tienen el mismo nivel de certeza.
hecho confirmado
→ evidencia disponible
supuesto
→ aceptado temporalmente
hipótesis
→ necesita prueba
restricción
→ limita alternativas
riesgo
→ evento incierto con impactoUn buen diseño no oculta incertidumbre. La registra, asigna responsable y define cómo validarla.
Solicitud inicial:
“Necesitamos una app para manejar pedidos.”Diseño superficial:
React + Node.js + PostgreSQLDiseño real:
La tecnología aparece después de comprender qué garantías necesita el sistema.
Puede ofrecer:
No garantiza:
El diseño es una hipótesis estructurada que debe mantenerse conectada con la realidad.
Parece avanzar rápido, pero encierra el problema dentro de decisiones prematuras.
Produce diagramas bonitos que nadie usa para decidir.
Aumenta complejidad antes de que exista evidencia.
Convierte documentación en una fotografía obsoleta.
Una especificación larga puede seguir siendo ambigua si no define reglas, límites ni criterios observables.
Incluso entonces deben existir problema, alcance, decisiones centrales y criterios de validación.
Descubrimiento del problema enseña a separar síntomas, causas, necesidades y soluciones antes de diseñar.