Uma saga gerencia uma transação comercial que se estende por vários serviços como uma sequência de transações locais. Se uma etapa falhar, a saga executa transações de compensação para desfazer etapas anteriores — não há rollback distribuído.
O commit de duas fases entre serviços é lento, bloqueia recursos e acopla a disponibilidade. Sagas proporcionam consistência eventual sem bloqueios distribuídos.
Os serviços reagem aos eventos uns dos outros; sem coordenador central.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
Um orquestrador diz a cada serviço o que fazer e reage aos resultados.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspecto | Coreografia | Orquestração |
|---|---|---|
| Coordenação | Distribuída (eventos) | Centralizada |
| Acoplamento | Mais frouxo | Orquestrador conhece o fluxo |
| Visibilidade | Difícil de seguir | Fácil de rastrear |
| Melhor para | Simples, poucos passos | Complexo, muitos passos |
As compensações devem ser idempotentes e lidar com o caso em que a etapa original teve êxito parcial. Projete-as com cuidado.
Sagas são como você mantém os dados consistentes em serviços sem o custo e o acoplamento de transações distribuídas.
Escolher entre coreografia e orquestração faz um trade-off de simplicidade por visibilidade: eventos escalam vagamente, mas ficam emaranhados, enquanto um orquestrador centraliza lógica complexa ao custo de um componente adicional para executar.