Saga Pattern

Table of Contents

🔴 P0 — the distributed transaction pattern for microservices; critical for Stripe payment flows

Problem #

2PC doesn’t scale across services. But business processes (order → payment → inventory → shipping) still need atomicity. How do you achieve “all or nothing” without distributed locks?

Mechanism #

A saga is a sequence of local transactions, each with a compensating transaction that undoes its effect.

Forward:
  T1: Create Order         → success
  T2: Charge Payment       → success
  T3: Reserve Inventory    → FAILS

Compensate (reverse order):
  C2: Refund Payment
  C1: Cancel Order

Two Coordination Styles #

Choreography: Each service listens for events and triggers the next step (or compensation). Decentralised. See also: Choreography vs Orchestration.
Orchestration: A central saga coordinator drives the workflow, calling each service and handling compensations.

Key Trade-offs #

Dimension	Saga	2PC
Atomicity	No (compensating instead of rollback)	Yes (true atomicity)
Isolation	No (intermediate states visible)	Yes (locks held until commit)
Availability	High (no distributed locks)	Lower (blocking protocol)
Complexity	Compensation logic per step	Simpler (commit/abort)
Scale	Works across services/DCs	Limited to few participants

Instinct #

Sagas are the standard for cross-service transactions in microservices.

The key design question is: “What does compensation look like for each step?”

For payments: compensation = refund.

For inventory: compensation = release reservation.

Always design compensation before the forward path. Orchestrated sagas are easier to reason about and debug for complex business processes.

References #

Sagas — Garcia-Molina & Salem (1987); original paper
microservices.io: Saga Pattern — Chris Richardson
Saga Pattern Made Easy with Temporal

DDIA 2e Reference #

Chapter 9: Limitations of 2PC, saga as alternative
Chapter 12: End-to-end correctness