Messaging, Events and Email Systems · Event-Driven Architecture
Sagas and Long-Running Workflows
Coordinate multi-service business processes without distributed transactions.
A saga is a sequence of local transactions with compensating actions for failures (refund the payment if shipping fails). Choreography: services react to each other's events — simple for short flows but hard to follow. Orchestration: a coordinator (or a workflow engine like Temporal, AWS Step Functions, Camunda) drives the steps, timeouts and compensations explicitly — better for complex flows. Design for retries, timeouts and visibility of workflow state.
Order saga (orchestrated)
1. Reserve inventory → on failure: end (nothing to undo)
2. Charge payment → on failure: release inventory
3. Create shipment → on failure: refund payment, release inventory
4. Mark order confirmed
Each step: idempotent, retried with backoff, with a timeout; state persisted after each step.
Common pitfalls
- Compensations that aren't idempotent or can fail silently.
- Choreography chains no one can trace end to end.
- Ignoring partial states visible to users (show 'processing').
Key points
- Local transactions + compensations
- Choreography vs orchestration
- Workflow engines for complex flows
Further reading: microservices.io: Saga
Practice questions
Why not use two-phase commit across microservices?
Answer
2PC couples services' availability, holds locks across the network, and is poorly supported by modern databases and brokers; sagas trade atomicity for availability with explicit compensation.
When is orchestration better than choreography?
Answer
For flows with many steps, branches, timeouts and compensations, where an explicit coordinator makes the process visible, testable and easier to change.
Open in the app to mark lessons complete, take notes and track your progress.