5 patrones de microservicios que probablemente no necesitás todavía.

Los sistemas que sobreviven no son los que tienen la mejor tecnología inicial — son los que fueron diseñados con criterio estructural desde el día uno. Y criterio, muchas veces, significa saber qué patrón no aplicar todavía.

Estos son cinco patrones que aparecen en casi toda conversación sobre sistemas distribuidos. Cada uno resuelve un problema real. La trampa está en adoptarlos antes de tener ese problema.

1. CQRS (Command Query Responsibility Segregation)

Separar las operaciones de lectura de las de escritura suena simple, pero el impacto es profundo. En sistemas donde las consultas son mucho más frecuentes que las escrituras — un desbalance habitual en enterprise — CQRS permite:

• Escalar lecturas independientemente con réplicas de solo lectura.
• Optimizar los modelos de datos para cada caso de uso.
• Bajar la latencia de consultas sin tocar el camino de escritura.

¿Cuándo usarlo? Cuando la ratio de lecturas vs escrituras es asimétrica y ese desbalance ya te está costando. Si tu base de datos todavía responde bien con un solo modelo, CQRS solo suma piezas que mantener.

2. Event Sourcing

En vez de guardar solo el estado actual, guardás cada evento que llevó a ese estado. Es como tener un Git para tus datos de negocio.

En dominios con requisitos fuertes de trazabilidad — seguros, finanzas, salud — esto habilita cosas que un modelo CRUD no puede:

• Reconstruir el historial completo de cualquier entidad de negocio.
• Auditoría real — cada cambio tiene timestamp, actor y contexto.
• Reprocesar eventos cuando las reglas de negocio cambian.

El costo es complejidad adicional, y no es menor. No lo uses en un CRUD simple. Pero cuando el negocio exige trazabilidad total, es imbatible.

3. Saga Pattern

Las transacciones distribuidas son el mayor dolor de cabeza en microservicios. El Saga Pattern resuelve esto con una cadena de transacciones locales, donde cada paso puede compensarse si algo falla.

Pensá en un pedido de e-commerce: validar inventario → reservar stock → procesar pago → confirmar envío. Si el pago falla, la saga libera el stock reservado automáticamente. Sin Saga, terminás con datos inconsistentes entre servicios.

Ahora la pregunta incómoda: ¿tenés transacciones que cruzan servicios? Si tu sistema es un monolito — o debería serlo — la transacción de base de datos que ya tenés hace esto gratis.

4. Circuit Breaker

Cuando un servicio externo falla, no querés que arrastre al resto del sistema. El Circuit Breaker detecta fallos recurrentes y “abre el circuito”, devolviendo una respuesta fallback instantánea en vez de esperar timeouts.

Es de los cinco el que antes se justifica: alcanza con depender de una API de terceros que se cae de vez en cuando. Bien implementado, la caída del proveedor se vuelve un evento operativo — el sistema sigue respondiendo con datos en caché o degradado con elegancia — en vez de una caída propia.

5. API Gateway

Un único punto de entrada para todos tus servicios. Parece básico, pero un API Gateway bien implementado te da:

• Autenticación centralizada — no duplicás lógica de auth en cada servicio.
• Rate limiting — protección contra abuso sin tocar la lógica de negocio.
• Transformación de requests — versionado de APIs sin romper clientes existentes.
• Observabilidad — un solo lugar para métricas, logs y tracing.

Con dos o tres servicios, un reverse proxy simple cumple el mismo rol con una fracción del costo operativo.

La clave: no usar todos a la vez

El error más común es adoptar estos patrones desde el día uno, como checklist de madurez. Nosotros evaluamos primero el contexto del negocio y las restricciones reales antes de elegir qué patrones aplican. A veces, un monolito bien estructurado es más valioso que una arquitectura distribuida prematura — ya escribimos sobre esto.

La arquitectura no es sobre complejidad — es sobre resolver los problemas correctos con las herramientas correctas. Y sobre tener la disciplina de no resolver los que todavía no tenés.