El monolito
Todo lo que has construido hasta ahora vive en una sola aplicación: un único proceso que se compila, prueba y despliega como un bloque. Eso es un monolito. Las capas (controlador → servicio → repositorio) están dentro del mismo despliegue y se llaman entre sí con simples llamadas a funciones.
El monolito tiene grandes virtudes: es simple de desarrollar, depurar y desplegar, y una llamada interna es instantánea. Para la mayoría de proyectos es la opción correcta. Sus límites aparecen cuando el equipo y el código crecen mucho: todo se despliega junto (un cambio pequeño obliga a redesplegar todo) y no puedes escalar solo la parte que lo necesita.
Microservicios
La alternativa son los microservicios: en vez de una aplicación grande, muchos servicios pequeños e independientes, cada uno responsable de una parte del dominio (usuarios, pagos, catálogo...). Cada servicio:
- Tiene su propio despliegue y su propio ciclo de vida (se publica solo).
- Suele tener su propia base de datos (no comparten tablas).
- Se comunica con los demás por la red: HTTP/gRPC para llamadas directas, o mensajes asíncronos a través de una cola o un bus.
Así, el equipo de pagos despliega cuando quiere sin tocar el de catálogo, y puedes escalar solo el servicio saturado. El precio es una fuerte complejidad operacional: la red puede fallar, hay que coordinar despliegues, observar muchos servicios y vivir sin transacciones que abarquen varios de ellos.
Arquitectura dirigida por eventos
Acoplar servicios con llamadas HTTP directas crea dependencias rígidas: si A llama a B, A necesita saber que B existe y esperar a que responda. La arquitectura dirigida por eventos (event-driven) le da la vuelta: en lugar de llamar, un servicio publica un evento ("PedidoCreado") en un bus de eventos, y otros servicios se suscriben a los eventos que les interesan. Es el patrón publicar/suscribir (pub/sub).
Pedidos ──(publica "PedidoCreado")──▶ Bus de eventos
├──▶ Facturación (suscrito)
└──▶ Email (suscrito)
El publicador no sabe quién escucha: para añadir una nueva reacción (avisar a logística) basta con suscribir otro servicio, sin tocar Pedidos. A cambio renuncias a la consistencia inmediata: los suscriptores reaccionan un poco después, así que el sistema vive en consistencia eventual (todo acaba cuadrando, pero no en el mismo instante).
Sagas a alto nivel. Cuando una operación abarca varios servicios (reservar stock, cobrar, enviar) no hay una transacción global. Se modela como una saga: una secuencia de pasos donde, si uno falla, se ejecutan acciones de compensación que deshacen los anteriores. En la variante por coreografía, no hay un coordinador central: cada servicio reacciona a los eventos de los demás y publica los suyos.
¿Cuándo dar el salto?
| Ventajas | Inconvenientes | |
|---|---|---|
| Monolito | Simple, rápido de desarrollar y desplegar | Se despliega y escala como un bloque |
| Microservicios | Escalado y despliegue independientes, autonomía de equipos | Complejidad operacional, red, consistencia eventual |
No es una elección de "mejor o peor", sino de compromiso. La mayoría de sistemas empiezan como un monolito bien estructurado en capas y solo extraen microservicios cuando el dolor del despliegue conjunto y el escalado lo justifica.