Una saga gestiona una transacción empresarial que abarca múltiples servicios como una secuencia de transacciones locales. Si un paso falla, la saga ejecuta transacciones compensatorias para deshacer pasos anteriores — no hay rollback distribuido.
Dos fases de commit en servicios es lento, bloquea recursos y acoplamiento de disponibilidad. Las sagas proporcionan consistencia eventual sin bloqueos distribuidos.
Los servicios reaccionan a los eventos entre sí; no hay coordinador central.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
Un orquestador le dice a cada servicio qué hacer y reacciona a los resultados.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspecto | Coreografía | Orquestación |
|---|---|---|
| Coordinación | Distribuida (eventos) | Centralizada |
| Acoplamiento | Más flexible | Coordinador conoce el flujo |
| Visibilidad | Difícil de seguir | Fácil de rastrear |
| Mejor para | Simple, pocos pasos | Complejo, muchos pasos |
Las compensaciones deben ser idempotentes y manejar el caso en que el paso original tuvo éxito parcialmente. Diseñalas cuidadosamente.
Las sagas son cómo mantienes la consistencia de datos entre servicios sin el costo y el acoplamiento de las transacciones distribuidas.
Elegir coreografía versus orquestación intercambia simplicidad por visibilidad: los eventos escalan flojamente pero se vuelven complicados, mientras que un orquestador centraliza la lógica compleja al costo de un componente más que ejecutar.