distributed-transactionsmicroservicesconsistencyorchestration
Saga Pattern
Coordinate multi-service workflows with local transactions and compensating actions.
Definition
Saga pattern breaks distributed transactions into ordered local steps with compensation for failures.
When To Use
- Cross-service workflows (order, payment, inventory, fulfillment).
- When two-phase commit is impractical at scale.
- Business flows requiring explicit failure recovery logic.
When Not To Use
- Simple single-database transactions.
- Domains lacking meaningful compensating actions.
- When eventual consistency windows are unacceptable.
Tradeoffs
- Enables distributed workflows, but requires explicit compensation complexity.
- Avoids global lock/2PC overhead, with eventual consistency side effects.
- Improves service autonomy, while increasing orchestration/observability burden.
Common Failure Modes
- Compensation failure leaves workflow in inconsistent terminal state.
- Duplicate saga events re-run irreversible steps.
- Timeouts and partial retries create customer-visible ambiguity.
Interview Framing
Use this structure when the interviewer asks for this pattern explicitly.
Define step boundaries, compensation semantics, idempotency strategy, and user-facing status model.
Related Project Deep Dives
Global E-Commerce & Payment Platform
Design a globally distributed commerce system with catalog, cart, inventory reservations, checkout orchestration, multi-PSP payments, fulfillment, and financial ledger correctness.
Ticket Booking & Seat Reservation System
Design a high-concurrency ticketing system with seat holds, anti-oversell guarantees, payment flows, and event surge handling.
Related Concepts
Idempotency Keys
Guarantee repeated client retries do not create duplicate side effects.
Transactional Outbox Pattern
Atomically persist business state and event records in one DB transaction, then publish asynchronously.
Event Sourcing
Persist state as an append-only event log and rebuild current state by replay.