Saga spravuje obchodní transakci, která se rozprostírá přes více služeb, jako sekvence lokálních transakcí. Pokud krok selže, saga spustí kompenzující transakce pro vrácení předchozích kroků — neexistuje žádné distribuované rollback.
Dvoustupňový commit přes služby je pomalý, blokuje prostředky a vázuje dostupnost. Sagas poskytují eventuální konzistenci bez distribuovaných zámků.
Služby reagují na události navzájem; není centrálního koordinátora.
Order ─OrderCreated→ Payment ─PaymentDone→ Inventory ─Reserved→ Shipping
◀───────── (on failure, each emits a compensating event) ─────────
Orchestrátor každé službě řekne, co má dělat, a reaguje na výsledky.
┌───────────── Saga Orchestrator ─────────────┐
▼ ▼ ▼ ▼
reservePayment reserveStock createShipment (on fail: compensate all)
| Aspekt | Choreografie | Orchestrace |
|---|---|---|
| Koordinace | Distribuovaná (události) | Centralizovaná |
| Vazba | Volnější | Koordinátor zná tok |
| Viditelnost | Těžko sledovatelná | Snadno stopy |
| Nejlepší pro | Jednoduché, pár kroků | Složité, mnoho kroků |
Kompenzace musí být idempotentní a zpracovávat případ, kdy původní krok částečně uspěl. Navrhněte je pečlivě.
Sagas jsou způsob, jak udržovat datovou konzistenci přes služby bez nákladů a vazby distribuovaných transakcí.
Volba choreografie versus orchestrace vyměňuje jednoduchost za viditelnost: události se škálují volně, ale jsou těžko sledovatelné, zatímco orchestrátor centralizuje složitou logiku na úkor jedné další součásti, kterou je potřeba spustit.