Si hay una frase que resume el oficio del arquitecto es esta: "depende". Casi ninguna decisión arquitectónica es buena o mala en absoluto; es buena o mala para un contexto concreto y unas prioridades concretas. Diseñar un sistema consiste, en el fondo, en una cadena de decisiones donde ganar en un atributo casi siempre implica ceder en otro. A estos sacrificios deliberados los llamamos trade-offs o compromisos. En esta lección aprenderás qué hace que una decisión sea "arquitectónica", cuáles son los compromisos más universales (empezando por el teorema CAP), cómo documentar decisiones con ADR y cómo evaluar arquitecturas de forma estructurada con el método ATAM.

1. Qué es una decisión arquitectónica significativa
2. El concepto de trade-off
3. Trade-offs clásicos
4. El teorema CAP
5. Documentar decisiones: los ADR
6. Evaluar la arquitectura: el método ATAM

No toda decisión técnica es arquitectónica. Una decisión es arquitectónicamente significativa (lo que la literatura llama Architecturally Significant Decision) cuando cumple una o varias de estas características:

• Alto coste de cambio: revertirla implicaría reescribir partes importantes del sistema.
• Amplio alcance: afecta a varios componentes, equipos o atributos de calidad.
• Impacto en atributos de calidad: condiciona el rendimiento, la seguridad, la disponibilidad, etc.
• Crea o elimina restricciones: abre o cierra opciones futuras.

Ejemplos de decisiones significativas: elegir entre monolito y microservicios, escoger el modelo de consistencia de datos, definir el mecanismo de autenticación, seleccionar el estilo de comunicación entre servicios. Ejemplos de decisiones no significativas: el nombre de una variable, el formato de indentación, qué librería de utilidades menor usar.

Un trade-off es un intercambio: para ganar algo, cedes otra cosa. En arquitectura, los recursos y los atributos de calidad están en tensión permanente.

Este diagrama Mermaid (graph LR, de izquierda a derecha) muestra que una sola decisión —añadir una caché— produce simultáneamente un efecto positivo (más rendimiento) y dos negativos (menos consistencia y más complejidad). La lección clave es que toda decisión tiene consecuencias en varias dimensiones a la vez, y el trabajo del arquitecto es hacerlas explícitas para decidir con los ojos abiertos.

La pregunta correcta nunca es "¿es buena esta opción?", sino "¿qué gano, qué pierdo, y compensa dadas mis prioridades?".

Estos compromisos aparecen una y otra vez en cualquier sistema:

Veamos el último en detalle:

La conclusión habitual: empezar con un monolito bien estructurado (a veces llamado "monolito modular") y extraer microservicios solo cuando el dolor concreto lo justifique. Saltar directo a microservicios "porque es lo moderno" es un error costoso muy frecuente.

El teorema CAP, formulado por Eric Brewer, es el trade-off más famoso de los sistemas distribuidos. Afirma que un sistema distribuido no puede garantizar las tres propiedades siguientes simultáneamente, solo dos:

• C — Consistencia (Consistency): toda lectura recibe el dato más reciente o un error.
• A — Disponibilidad (Availability): toda petición recibe una respuesta (aunque no sea el dato más reciente).
• P — Tolerancia a particiones (Partition tolerance): el sistema sigue funcionando aunque se pierda la comunicación entre nodos.

La clave que muchos pasan por alto: en un sistema distribuido real, las particiones de red ocurren, no son opcionales. Por tanto, la P es obligatoria, y la elección real es entre C y A cuando hay una partición.

Este diagrama Mermaid ilustra que el dilema CAP solo se manifiesta durante una partición. Cuando no hay partición, un sistema puede ofrecer consistencia y disponibilidad. Cuando la hay, debe elegir: un sistema CP prefiere rechazar peticiones antes que devolver un dato incorrecto (típico en banca); un sistema AP prefiere seguir respondiendo aunque el dato pueda estar desactualizado (típico en redes sociales o catálogos).

Un matiz importante: en la práctica, la consistencia no es binaria. Muchos sistemas usan consistencia eventual, donde los datos convergen al valor correcto tras un breve periodo. El modelo PACELC extiende CAP para considerar también el trade-off entre latencia y consistencia cuando no hay particiones.

Una decisión arquitectónica que solo vive en la cabeza de quien la tomó está perdida. Los ADR (Architecture Decision Records, registros de decisiones arquitectónicas) son documentos breves que capturan una decisión y, sobre todo, su porqué. Popularizados por Michael Nygard, son hoy una práctica estándar.

Un ADR típico tiene esta estructura:

Este ADR está escrito en Markdown y sigue el formato de Nygard. Las secciones clave son: Estado (propuesta, aceptada, obsoleta, sustituida), Contexto (el problema y las fuerzas en juego), Decisión (qué se decide, en presente y de forma afirmativa) y Consecuencias (los trade-offs, tanto buenos como malos, escritos honestamente). Lo más valioso es la sección de Consecuencias negativas: documentar lo que sacrificamos evita que en el futuro alguien "redescubra" el problema y cuestione la decisión sin entender por qué se tomó. Los ADR se guardan versionados junto al código (por ejemplo, en una carpeta docs/adr/).

¿Cómo saber si una arquitectura propuesta es adecuada antes de construirla? El ATAM (Architecture Tradeoff Analysis Method), desarrollado por el SEI, es un método estructurado para evaluar arquitecturas analizando precisamente sus trade-offs frente a los atributos de calidad prioritarios.

Pasos esenciales del ATAM (simplificados):

1. Presentar el método a los participantes (negocio y técnicos).
2. Presentar los business drivers: objetivos de negocio y atributos de calidad prioritarios.
3. Presentar la arquitectura propuesta.
4. Identificar enfoques arquitectónicos (patrones y tácticas usados).
5. Construir el árbol de utilidad (utility tree): se descomponen los atributos de calidad en escenarios concretos, priorizados por importancia y por riesgo.
6. Analizar los enfoques frente a los escenarios prioritarios.
7. Identificar puntos clave, en tres categorías.
8. Presentar resultados.

En el paso 7, ATAM clasifica los hallazgos en tres tipos muy útiles incluso fuera del método formal:

ATAM completo es un proceso pesado, pensado para sistemas críticos. Pero su filosofía es aplicable siempre: evalúa la arquitectura contra escenarios de calidad priorizados y haz explícitos los puntos de compromiso y los riesgos. Incluso una versión ligera, en una pizarra y un par de horas, aporta enorme valor.

• Tomar decisiones por moda. "Microservicios porque está de moda" ignora el contexto. Decide según tus atributos prioritarios, no según el hype.
• No documentar el porqué. Sin ADR, las decisiones se cuestionan eternamente y se pierde el conocimiento al rotar el equipo.
• Ocultar las consecuencias negativas. Un buen ADR es honesto sobre lo que se sacrifica. Maquillar los trade-offs lleva a sorpresas dolorosas.
• Creer que existe la decisión "correcta". Casi todo es un compromiso. Busca la decisión adecuada para tus prioridades, no la perfecta.
• Consejo: prioriza antes de decidir. Pide al negocio que ordene los atributos de calidad. Sin prioridades, no se pueden resolver los trade-offs.

Ejercicio 1. Para un sistema de saldos bancarios y para un feed de una red social, indica si elegirías CP o AP ante una partición de red, y justifícalo.

Ejercicio 2. Escribe un ADR breve (estado, contexto, decisión, consecuencias) para la decisión "Adoptar una base de datos relacional única en lugar de una base de datos por microservicio" en una aplicación que aún es pequeña.

Ejercicio 3. En la decisión "introducir una caché distribuida delante de la base de datos", identifica un punto sensible, un punto de compromiso y un riesgo según la terminología de ATAM.

Solución 1. Saldos bancarios: CP. Es preferible rechazar una operación (no estar disponible momentáneamente) antes que mostrar o permitir operar sobre un saldo incorrecto; la consistencia es crítica. Feed de red social: AP. Es preferible seguir mostrando contenido (aunque falte la última publicación) antes que dejar de responder; la disponibilidad pesa más que ver el dato exacto al instante.

Solución 2. Ejemplo: Estado: Aceptada. Contexto: La aplicación es pequeña, el equipo reducido y el dominio aún no está estabilizado; gestionar varias bases de datos añadiría complejidad operativa y de consistencia sin beneficio claro. Decisión: Usar una única base de datos relacional compartida por los módulos, manteniéndolos lógicamente separados (monolito modular). Consecuencias: Positivas: transacciones simples, consistencia fuerte, menor coste operativo, desarrollo más rápido. Negativas: acoplamiento a un único esquema, posible cuello de botella al escalar y mayor esfuerzo futuro si se quiere migrar a base de datos por servicio.

Solución 3. Punto sensible: el tiempo de expiración (TTL) de la caché afecta decisivamente al rendimiento (cuánto se aprovecha la caché). Punto de compromiso: la caché mejora el rendimiento pero perjudica la consistencia (datos potencialmente obsoletos) y aumenta la complejidad. Riesgo: una estrategia de invalidación incorrecta podría servir datos obsoletos a los usuarios o, peor, provocar incoherencias difíciles de detectar.

Has aprendido a reconocer qué hace que una decisión sea arquitectónicamente significativa, a razonar en términos de trade-offs, a manejar los compromisos clásicos y el teorema CAP, a documentar decisiones con ADR honestos y a evaluar arquitecturas con la filosofía de ATAM. La idea que vertebra todo el capítulo es que la arquitectura es el arte de elegir conscientemente qué sacrificar. Pero de nada sirven decisiones brillantes si nadie las entiende ni puede comunicarse al equipo: en la siguiente y última lección del módulo aprenderás a documentar la arquitectura mediante vistas y el modelo C4, para que tus decisiones se transmitan con claridad.