No distributed transaction
Across services you cannot hold one lock over many databases. A saga coordinates a long running business transaction as a series of local steps, each in its own service, linked by events. If a step fails, earlier steps are undone by compensating actions.
Choreography style
In an event driven saga, each service reacts to events and emits its own.
- Order service emits order created.
- Payment service charges and emits payment captured, or payment failed.
- Inventory service reserves stock and emits stock reserved, or stock rejected.
A failure event triggers compensations such as refund payment or release stock.
Tradeoffs
- No global lock, so services stay independent and available.
- Eventual consistency, since the whole flow settles over time.
- Compensations are real work and must themselves be idempotent and reliable.
Key idea
A saga splits a cross service transaction into local steps linked by events, using compensating actions to undo work when a later step fails.