La Ley de los Trade-offs
Nivel intermedio — internalizar que toda decisión arquitectónica implica sacrificar algo, y aplicar un framework para evaluarlo sistemáticamente.
El problema
Los arquitectos novatos buscan soluciones óptimas universales: "la mejor" tecnología, "el mejor" patrón. Pero esa pregunta está mal planteada.
Situación típica: el equipo debate PostgreSQL vs. MongoDB. Alguien encuentra un artículo que dice que MongoDB escala mejor; otro encuentra uno que dice que PostgreSQL es más confiable. El debate se vuelve religioso porque ambos buscan "la mejor" base de datos, ignorando que la respuesta real es depende de qué estés optimizando. // sin trade-off explícito, no hay forma de zanjar el debate
Si no articulas qué sacrificaste y por qué, tomas decisiones por hype o preferencia personal — y no puedes defenderlas cuando alguien las cuestiona.
Las dos leyes
Formuladas por Mark Richards y Neal Ford:
La primera dice que no hay decisión sin coste. La segunda dice que el motivo de negocio detrás de una decisión importa más que el mecanismo técnico elegido para ejecutarla.
Trade-offs universales en software
| Si optimizas... | Probablemente sacrificas... |
|---|---|
| Velocidad de desarrollo | Rendimiento en runtime |
| Rendimiento | Mantenibilidad del código |
| Flexibilidad | Simplicidad |
| Consistencia de datos | Disponibilidad |
| Escalabilidad | Coste de infraestructura |
| Seguridad | Experiencia de usuario |
| Time-to-market | Calidad técnica |
Framework RADAR
Cinco preguntas para evaluar trade-offs sin caer en el debate religioso:
Principio "Least Worst": no busques la mejor solución — busca la menos mala para tu contexto específico. Toda opción tiene problemas; elige los problemas que puedes manejar.
Cuándo aplicarlo
| Análisis formal de trade-offs si... | Decisión rápida es suficiente si... |
|---|---|
| La decisión es costosa de revertir (>2 semanas) | Es fácilmente reversible (<2 días) |
| Afecta a múltiples equipos o sistemas | Afecta solo tu código local |
| Tiene implicaciones de coste significativas | El coste es trivial |
| El equipo tiene opiniones divididas | Hay consenso claro |
Dos arquitectos aplicando bien el mismo RADAR pueden llegar a conclusiones distintas si priorizan atributos de calidad distintos — y eso es correcto, no un fallo del framework. La Segunda Ley lo dice: el "por qué" de negocio decide, no el mecanismo. RADAR ordena el análisis; no elimina el juicio.
Practica: comunicación entre servicios
Tu equipo debe decidir cómo comunicar los servicios de un e-commerce (Catálogo, Carrito, Pedidos, Pagos, Inventario). Opciones: REST síncrono, gRPC síncrono, o mensajería asíncrona con RabbitMQ.
Aplica RADAR y documenta tu decisión en formato ADR: contexto, alternativas consideradas, decisión, y consecuencias (qué ganas, qué sacrificas).