System Design
Explica cómo comparar alternativas, hacer visibles criterios, costes y consecuencias y registrar decisiones revisables en lugar de buscar una arquitectura perfecta.
Una decisión de diseño no es “la mejor práctica”. Es una elección contextual entre alternativas que optimizan cosas distintas y producen consecuencias que deben vigilarse.
Diseñar es decidir bajo restricciones e incertidumbre. Cada alternativa mejora algunos drivers y empeora otros: coste, latencia, consistencia, mantenibilidad, velocidad de entrega, seguridad u operación.
contexto + drivers + restricciones
→ alternativas reales
→ evidencia
→ trade-offs
→ decisión
→ consecuencias
→ trigger de revisiónUna elección merece registro cuando es costosa de revertir, afecta varios equipos, modifica una cualidad importante o será cuestionada en el futuro.
Ejemplos:
Los drivers explican qué se intenta optimizar. Las restricciones eliminan alternativas.
Driver: integridad de inventario
Restricción: equipo pequeño sin operación 24/7
Consecuencia: una solución distribuida puede ofrecer escalado, pero aumentar un riesgo operacional más importante.Pueden probarse con bajo coste: formato de una vista interna o una librería encapsulada.
Modelo de datos central, API pública, particionamiento o proveedor con gran dependencia.
Invierte más evidencia en decisiones irreversibles y conserva opciones en las reversibles.
Título
Estado: propuesto | aceptado | reemplazado | deprecado
Contexto y problema
Drivers y restricciones
Alternativas consideradas
Decisión
Consecuencias positivas
Consecuencias negativas y riesgos
Evidencia
Trigger de revisión
Fecha, owner y enlacesEl ADR conserva por qué se decidió, no solo qué quedó implementado.
SaaS multi-tenant con pedidos, inventario, pagos y reportes operativos.
Integridad transaccional, consultas relacionales, experiencia del equipo y operación sencilla.
PostgreSQL, base documental gestionada y combinación polyglot desde el inicio.
Usar PostgreSQL como fuente transaccional principal.
Constraints, transacciones, SQL, ecosistema maduro y menor complejidad operacional.
Escalado de escritura y algunas proyecciones pueden requerir trabajo posterior; el esquema debe migrarse cuidadosamente.
Una carga o patrón de acceso medido que no pueda resolverse razonablemente con índices, réplicas, partición o proyecciones.
Una caché puede reducir latencia —primer orden—, pero introducir invalidación, staleness, observabilidad y coste —segundo orden—. Un buen análisis no se detiene en la ventaja inmediata.
No se decide para todo el sistema. Reservar stock puede necesitar una garantía fuerte; un dashboard puede aceptar retraso.
Una plataforma configurable atiende más casos, pero añade estados y reglas. Una solución específica entrega antes y resulta más comprensible.
Comprar reduce tiempo inicial, pero introduce coste recurrente, límites, dependencia y migración futura. Construir ofrece control, con mayor desarrollo y operación.
Una capacidad compartida reduce duplicación, pero puede convertirse en cuello organizacional y técnico.
Las decisiones pueden apoyarse en:
Opinión y popularidad no sustituyen evidencia.
Una decisión puede ser correcta ahora y equivocada después. Registra condiciones de validez y triggers:
mantener despliegue en una región
hasta que clientes o RTO exijan redundancia regionalUn estándar organiza elecciones repetidas. Aun así, debe explicar contexto y excepciones. “Siempre usamos X” no elimina la necesidad de evaluar si el problema encaja.
Una restricción legal o contractual puede eliminarla antes de puntuar beneficios.
Documenta incertidumbre, ejecuta experimento o elige la opción más reversible.
No la mantengas solo por antigüedad. Investiga qué restricciones originales siguen vigentes.
Reabre el ADR en lugar de reescribir la historia como si la decisión anterior hubiera sido absurda.
Matrices de decisión estructura criterios y evidencia sin ocultar restricciones ni incertidumbre.