Software Architect · Módulo 02
En arquitectura casi nunca existe la opción 'correcta'. Existe la opción 'estamos comprando esta propiedad a este precio, conscientemente'.
Latency · consistency · maintainability · cost of complexity
El arquitecto no caza best practices. Nombra los ejes de la elección y el precio que se paga en cada uno.
Una decisión sin precio no es una decisión
Un avión es más rápido que un tren, pero es más caro, depende del clima y no te deja en el centro de la ciudad. "El avión es mejor" es mala conversación arquitectónica.
Un trade-off es cambiar una propiedad por otra. Los ejes más comunes en sistemas: latency vs. throughput, consistency vs. availability, simplicity vs. flexibility, time-to-market vs. maintainability, costo operacional vs. velocidad de desarrollo, vendor control vs. costo de build.
La versión profesional de esta conversación suena así: "Vamos con managed Postgres porque el equipo es chico y nos importa más la velocidad operativa que el control total del storage layer". O: "No introducimos Kafka ahora porque no necesitamos replay ni high throughput, y la operational complexity sería real ya mañana".
La complejidad tiene que comprar una capacidad concreta
Podés cocinar en un monoambiente equipado con una cocina industrial. Vivir ahí, en cambio, es más difícil.
La complejidad no siempre es mala. A veces hace falta: multi-region, event sourcing, sharding, service mesh, CQRS, Kubernetes. Pero cada una de esas cosas tiene que comprar una propiedad concreta que ya importa o que casi seguro va a importar.
Si el equipo no puede nombrar qué está comprando la complejidad, eso es típicamente over-engineering. Si el equipo ignora un dolor real existente en nombre de la simplicidad, eso es under-engineering.
Un trade-off sólo es útil cuando efectivamente cambia la decisión.
Ejemplo: REST o GraphQL
Una carta de restaurante funciona cuando los platos son estándar. Un armador de ensaladas funciona cuando cada cliente quiere su propia combinación.
REST encaja cuando los recursos son estables, el caching ayuda, los clientes se parecen entre sí y la API tiene que ser simple para integraciones externas. GraphQL va bien cuando hay muchos clientes, las formas de los datos varían y el frontend sufre seguido por overfetching o underfetching.
El trade-off: GraphQL le da flexibilidad al cliente pero complica observability, authorization a nivel de campo, caching, rate limiting y performance control. REST es más simple operacionalmente, pero puede multiplicar endpoints y forzar a los clientes a hacer varias round trips.
Un aeropuerto tiene torre de control. Eso no quiere decir que la bicicletera la necesite.
Copiar la arquitectura de Netflix, Uber o Amazon sin su escala es cargo cult. Las grandes empresas tienen otras cargas, otros equipos, otro compliance, otro legacy y otro costo de caída. Su decisión puede ser correcta en su contexto y dañina en el tuyo.
El arquitecto tiene que poder decir: "Sí, es un industry pattern. No, nuestro problema todavía no llegó ahí".
- ¿Sobre qué ejes de trade-off se apoya la decisión actual? - ¿Qué nos está comprando la complejidad? - ¿Qué pasa si elegimos la opción más simple? - ¿Qué señal nos va a indicar que es hora de sumar complejidad?