Saga Pattern
The Saga pattern coordinates distributed transactions across multiple services by composing local transactions with compensations to maintain overall consistency.
Classification
- ComplexityHigh
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Incomplete compensations create inconsistencies
- Duplicate execution due to retries
- Distributed deadlocks from faulty choreography
- Use idempotent handlers
- Persist saga state
- Build end-to-end observability
I/O & resources
- Business process steps
- Compensation logic
- Service interfaces
- Consistent overall state
- Compensation events
- Auditable execution trail
Description
The Saga pattern is an architectural concept for distributed systems that models a business workflow as a sequence of local transactions. Each local transaction commits independently and triggers compensating actions on failure to restore overall state. This enables eventual consistency without a central, blocking two‑phase commit.
✔Benefits
- No global lock or 2PC required
- Scales across service boundaries
- Failures can be handled via compensation
✖Limitations
- Complex failure and compensation logic
- Only eventual consistency
- Higher observability requirements
Trade-offs
Metrics
- Compensation rate
Share of sagas that require compensation.
- End-to-end duration
Time to complete a saga.
- Step failure rate
Share of failed local transactions per step.
Examples & implementations
E‑commerce checkout
Payment, inventory, and shipping are modeled as saga steps with compensations on failure.
Booking platform
Flight, hotel, and car rental are local transactions that are compensated on conflicts.
Account migration
User accounts, subscriptions, and permissions are migrated stepwise with compensations on errors.
Implementation steps
Decompose the process into local transactions
Define compensation paths
Choose orchestration or choreography
⚠️ Technical debt & bottlenecks
Technical debt
- Inconsistent compensation logic
- Manual intervention for saga failures
- Missing restart strategies
Known bottlenecks
Misuse examples
- Using sagas for strictly consistent financial postings
- Compensation without idempotency
- Choreography without clear event contracts
Typical traps
- Forgetting side effects in compensation
- Missing timeouts and retries
- Insufficient visibility of saga state
Required skills
Architectural drivers
Constraints
- • Strict compliance requirements
- • Service boundaries are fixed
- • Limited transaction windows