System Design Practice

System Design is synthesis

Este mapa conecta prácticas para pasar de un problema ambiguo a decisiones arquitectónicas explicables y evaluables. System Design combina conocimiento: no crea una segunda definición de Quality Attributes, drivers, constraints, profiles ni mecanismos de resiliencia. Los enlaces conducen a los canónicos que conservan esas responsabilidades; las prácticas muestran cómo utilizarlos en un problema situado.

No se limita a entrevistas, servicios distribuidos o sistemas con millones de usuarios. Una aplicación de un proceso y una base puede necesitar decisiones significativas; una plataforma grande puede conservar partes sencillas. El punto de entrada es el problema y sus compromisos, no una lista de tecnologías habituales.

Fundamentos de la práctica

Pregunta	Recorrido
¿Cómo paso de un problema ambiguo a una propuesta arquitectónica evaluable?	design-process: candidatos, decisiones, evidencia, convergencia y revisión.
¿Cómo convierto necesidades, Quality Attributes y constraints en drivers útiles para diseñar?	requirements-to-architecture: aclaración, significancia, prioridad e implicaciones.

Requirements to Architecture se concentra en interpretar la entrada; Design Process incluye el ciclo más amplio de desarrollar y evaluar propuestas. Pueden recorrerse varias veces. Una pregunta de diseño puede revelar un requisito incompleto, y una medición puede invalidar un supuesto que parecía cerrado.

Dar forma e investigar el diseño

Pregunta	Recorrido
¿Cómo represento las decisiones principales con suficiente detalle para razonar sobre la arquitectura?	high-level-design: alcance, vistas, compromisos y riesgos visibles.
¿Qué parte del diseño merece investigación adicional por riesgo, significancia o incertidumbre?	deep-dives: pregunta enfocada, alternativas, evidencia y cierre.

HLD ofrece síntesis general y expone preguntas; Deep Dives profundiza selectivamente y puede modificarla. Ambas prácticas pertenecen al ciclo de diseño, sin imponer fases cerradas ni una taxonomía universal. «High level» depende del alcance; «profundizar» necesita una pregunta y no una cantidad de páginas.

Comparar y cuantificar decisiones

Pregunta	Recorrido
¿Cómo comparo alternativas sin reducir arquitectura a pros y contras genéricos?	trade-off-analysis: criterios desde drivers, consecuencias, evidencia, incertidumbre y razones para decidir.
¿Qué cantidades necesito aproximar para comprobar que una decisión es plausible?	estimation: supuestos, unidades, rangos y límites de las cuentas.

Trade-off Analysis compara alternativas; Estimation produce evidencia cuantitativa aproximada. Pueden alimentarse: una comparación descubre qué cantidad importa y una estimación puede cambiar el candidato preferido. Una matriz no decide por sí misma y una cifra no elimina incertidumbre. Estos recorridos son una organización inicial del Atlas, no una taxonomía universal del diseño.

Revisar y practicar la síntesis

Pregunta	Recorrido
¿Qué errores recurrentes distorsionan una decisión aunque las tecnologías sean razonables?	common-pitfalls: consecuencias ocultas, supuestos, evidencia y preguntas correctivas.
¿Cómo practico System Design sin memorizar una única arquitectura correcta?	design-exercises: problemas acotados, decisiones, perturbaciones y revisión de razones.

Common Pitfalls ofrece lentes de revisión; Design Exercises integra las prácticas en problemas abiertos a más de una respuesta defendible. Pueden utilizarse al comienzo, al contrastar una propuesta o después de recibir evidencia. No constituyen una fase final obligatoria ni un checklist o examen universal.

Elegir el conocimiento que necesita la pregunta

architecture-foundations permite recuperar vocabulario y alcance. architectural-significance ayuda a decidir dónde concentrar atención; architectural-drivers conecta esa atención con necesidades y restricciones. No todo ticket demanda una revisión arquitectónica ni toda decisión pequeña tiene consecuencias locales.

quality-attributes organiza resultados evaluables, escenarios, prioridades y compromisos. Conviene ir a quality-attribute-scenarios cuando «rápido», «disponible» o «fácil de cambiar» no permiten contrastar una propuesta. La práctica utiliza escenarios relevantes, sin exigir métricas arbitrarias ni volver a definir cada quality.

architecture-decision-axes permite interrogar responsabilidades, dependencias, interacción, autoridad, aislamiento, tenants, entrega, ejecución y crecimiento. Son dimensiones analíticas; llenarlas no demuestra calidad. Una incertidumbre concreta determina qué ejes conviene profundizar y qué relaciones entre ellos deben quedar visibles.

architecture-profiles ofrece paquetes candidatos que necesitan evaluación. No representa una escala de madurez ni una respuesta automática a requisitos de crecimiento. architectural-pattern aporta conocimiento reutilizable cuando su contexto corresponde; acumular nombres no produce una arquitectura coherente.

Un recorrido desde Commerce

Commerce necesita aceptar pedidos, autorizar pagos, reservar inventario y organizar envíos. «Checkout rápido y disponible» todavía deja abiertas preguntas sobre carga, frontera, fallo del proveedor y resultado prometido. Empezar por requirements-to-architecture para convertir esas expresiones en compromisos discutibles con negocio, operación y consumidores.

Si Payments necesita cambiar de proveedor, preguntar si basta localizar cambios internos o si se exige entrega independiente de Orders. interfaces, deployment y deployability permiten discutir esa diferencia. No se elige Microservices por la sola presencia de dos responsabilidades o dos equipos.

Continuar con design-process para comparar direcciones viables y buscar evidencia que las distinga. Un proveedor SOAP contractual restringe una integración; no decide la arquitectura completa. Un prototipo puede comprobar compatibilidad, pero necesita declarar qué no demuestra sobre fallos, volumen, costo o soporte.

high-level-design permite representar responsabilidades y sus realizaciones sin asumir cuatro Microservices. deep-dives puede investigar reservas concurrentes de Inventory, autorización con resultado incierto o capacidad limitada por el proveedor. Los hallazgos vuelven a la síntesis: pueden justificar otra frontera o mostrar que separar no aporta beneficio suficiente.

Para la frontera de Payments, trade-off-analysis compara deployment común e independiente según evolución, checkout, aislamiento, operación y equipo. estimation aproxima tráfico, concurrencia, almacenamiento y demanda frente a cuotas cuando esos números discriminan opciones. Ninguna práctica elige Microservices por defecto ni convierte el volumen medio de pedidos en capacidad de pico.

Si el sistema ya opera, evolution-and-modernization mantiene presentes comportamiento, consumidores e historia. migration-strategy incorpora estados de transición. Las autorizaciones nuevas pueden funcionar mientras refunds y reportes todavía necesitan caminos anteriores: la propuesta objetivo no explica por sí sola cómo llegar ni qué puede retirarse.

Evidencia y decisiones revisables

Una síntesis posible del Atlas conecta problema, requisitos aclarados, drivers, candidatos, contraste, propuesta y evidencia de implementación. No es un orden obligatorio ni una metodología formal. La pregunta útil en cada revisión es qué compromiso se sostiene y qué observación haría reconsiderarlo.

fitness-functions puede aportar feedback seleccionado; no todo juicio necesita automatización. quality-attribute-trade-offs ayuda a declarar consecuencias aceptadas y necesidades en tensión. Mantener supuestos visibles permite revisar una decisión cuando cambia el workload o se descubre un límite externo.

El diseño necesita converger lo suficiente para construir el próximo alcance. Explorar indefinidamente retrasa aprendizaje; fijar todas las decisiones antes de comprender los drivers puede hacer costosa la corrección. El equilibrio depende de significancia, reversibilidad y riesgo, no de una cantidad universal de diagramas.

Alcance de este recorrido

Los ocho temas de System Design Practice previstos por Knowledge Map V0.3 tienen canonical y navegación en este mapa. Esto completa materialmente esa rama, sin convertir sus documentos draft en conocimiento definitivo ni cerrar su revisión futura. La organización pertenece al Atlas y no prescribe un lifecycle formal para toda arquitectura.

Requirements to Architecture aclara entradas; Design Process mantiene el ciclo; HLD sintetiza; Deep Dives investiga; Trade-off Analysis compara; Estimation aproxima; Common Pitfalls ayuda a revisar; Design Exercises practica su integración. Una estimación puede revelar otra constraint, una investigación cambiar HLD y el feedback de un ejercicio volver al encuadre. Volver al canonical correspondiente cuando falte entender un mecanismo y a estos recorridos cuando el problema sea combinarlo, sin duplicarlo por contexto de uso.