Estilos Arquitectónicos
Nivel intermedio-avanzado — evaluar y seleccionar el estilo arquitectónico adecuado según contexto, restricciones y atributos de calidad priorizados.
El problema
La industria sufre de "architecture hype": microservicios se venden como solución universal, serverless como el futuro inevitable. Equipos adoptan estilos porque "Netflix lo usa", ignorando que cada estilo optimiza para atributos distintos.
Situación típica: una startup de 5 desarrolladores decide usar microservicios "para escalar desde el inicio". Seis meses después: 12 servicios, ninguno con más de 500 líneas de código útil, un mes de trabajo perdido configurando Kubernetes, y cada feature simple requiere coordinar cambios en 4 repositorios. // el estilo es la decisión más costosa de revertir
Los 4 estilos
1. Monolito Modular
Aplicación desplegada como una unidad, organizada internamente en módulos con límites claros.
Ventajas
- Simplicidad de dev/testing/deploy
- Llamadas entre módulos = nanosegundos
- Transacciones ACID triviales
Desventajas
- Escala como unidad completa
- Un bug puede tumbar todo
- Tentación de violar límites de módulo
2. Microservicios
Servicios pequeños, desplegables de forma independiente, comunicados por red.
Ventajas
- Deploy y escala independiente
- Equipos autónomos
- Libertad tecnológica (polyglot)
Desventajas
- Complejidad operacional exponencial
- Transacciones distribuidas difíciles
- Debugging distribuido requiere tracing
// "Si no tienes los problemas que los microservicios resuelven, solo heredas los problemas que crean" — la Ley de los Microservicios
Prerrequisitos antes de adoptarlos: CI/CD maduro, infraestructura como código, observabilidad robusta, bounded contexts ya estables.
3. Event-Driven Architecture (EDA)
Componentes que se comunican produciendo y consumiendo eventos en vez de llamadas directas.
Ventajas
- Desacoplamiento temporal y espacial
- Escalabilidad horizontal de consumers
- Replay de eventos para debugging
Desventajas
- Debugging complejo (flujo no lineal)
- Consistencia eventual
- Ordenamiento de eventos desafiante
| Patrón EDA | Descripción | Caso de uso |
|---|---|---|
| Event Notification | Notifica que algo pasó | Email al registrarse |
| Event-Carried State Transfer | Evento lleva datos completos | Sincronizar catálogo a búsqueda |
| Event Sourcing | Estado se deriva de eventos | Auditoría financiera |
| CQRS | Separa modelo de escritura/lectura | Queries complejas eventualmente consistentes |
4. Serverless
Ejecución de código sin gestionar servidores, pagando solo por tiempo de ejecución.
Ventajas
- Cero gestión de infraestructura
- Escala a cero
- Pago por uso real
Desventajas
- Vendor lock-in significativo
- Cold starts (100ms-3s)
- Límites de ejecución (15 min en Lambda)
Matriz comparativa
| Criterio | Monolito Modular | Microservicios | EDA | Serverless |
|---|---|---|---|---|
| Complejidad inicial | Baja | Alta | Media-Alta | Baja |
| Complejidad operacional | Baja | Muy alta | Alta | Baja* |
| Escala independiente | No | Sí | Sí | Sí |
| Latencia entre componentes | ns | ms | ms+ | ms+ |
| Consistencia de datos | ACID fácil | Eventual | Eventual | Eventual |
| Vendor lock-in | Bajo | Bajo | Medio | Alto |
| Costo de entrada | Bajo | Alto | Medio | Bajo |
*Baja si aceptas las limitaciones del vendor.
Estos valores son relativos y genéricos — "complejidad alta" en microservicios no es la misma cifra para un equipo de 5 que para uno de 50. Usa la matriz para comparar estilos entre sí, no como tabla de puntuación absoluta. La decisión real sale de cruzarla con tus restricciones (Lección 2.3) y atributos priorizados (Lección 1.4).
Practica: plataforma de delivery de comida
Tu empresa va a construir: app móvil para clientes, app para repartidores, panel para restaurantes, asignación de repartidores en tiempo real, procesamiento de pagos, y notificaciones push en tiempo real.
Elige el estilo arquitectónico (o combinación), documenta los trade-offs con la matriz, y define un plan de evolución incremental si empiezas más simple de lo que el sistema necesitará a futuro.