Why Sagas Replace Distributed Transactions
In a monolith, a multi-step business operation like 'place order, reserve inventory, charge payment' can be wrapped in a single ACID database transaction: if any step fails, the whole thing rolls back atomically. Once those steps live in separate services with separate databases (per the database-per-service pattern), you can't use one transaction anymore. The classic distributed alternative, two-phase commit (2PC), requires a coordinator to lock resources across all participants until every service votes to commit, which does not scale well, doesn't work across heterogeneous systems like message queues, and creates availability risk — if the coordinator or any participant is down, everything blocks. The Saga pattern solves this by breaking the operation into a series of local transactions, each committed independently, with a defined compensating transaction to semantically undo each step if a later one fails.
Cricket analogy: A DRS review that locks the entire ground — batsmen, bowlers, fielders all frozen — until the third umpire confirms is like 2PC's global lock; a saga instead lets play continue and simply reverses a decision (recalling a batsman) if the review later fails.
Choreography vs. Orchestration
There are two ways to coordinate a saga's steps. In choreography, there is no central coordinator: each service publishes an event when it completes its local transaction, and the next service in the flow subscribes to that event and reacts, publishing its own event in turn. This keeps services fully decoupled but makes the overall business process hard to see — you have to trace events across many services to understand the flow, and adding a new step means modifying multiple existing services' subscriptions. In orchestration, a dedicated saga orchestrator (sometimes a simple state machine, sometimes a workflow engine like Temporal, AWS Step Functions, or Camunda) explicitly calls each service in sequence and decides what to do on failure. Orchestration centralizes the business logic, making it easier to reason about and monitor, at the cost of introducing a new component that itself needs to be built reliably.
Cricket analogy: Choreography is like fielders reacting purely to the ball and calling to each other as it happens with no captain directing traffic, while orchestration is the captain at mid-on calling every fielder's position and reacting to each ball centrally.
Compensating Transactions in Practice
A compensating transaction is not a database rollback — it's a new, separate business operation that semantically reverses an already-committed step. If the Payment service already charged a customer's card and the Shipping service then discovers the item is out of stock, the compensation isn't 'undoing' the charge as if it never happened; it's issuing a refund, a distinct, auditable transaction. This matters because the original transaction may have had external side effects (an email confirmation sent, a loyalty point awarded) that a raw rollback can't undo. Compensations must also be idempotent and retriable, because in a distributed system the same compensation message might be delivered more than once, and must also handle the awkward case where the compensation itself fails, often requiring a dead-letter queue and manual intervention or a retry-with-backoff strategy.
Cricket analogy: When an umpire's on-field decision is overturned by DRS after the batsman has already walked off and the crowd has reacted, the 'compensation' is recalling the batsman and adjusting the scorecard, not pretending the walk-off never happened.
// Simplified orchestrated saga for an e-commerce checkout
type SagaStep = {
name: string;
action: () => Promise<void>;
compensate: () => Promise<void>;
};
async function runSaga(steps: SagaStep[]) {
const completed: SagaStep[] = [];
try {
for (const step of steps) {
await step.action();
completed.push(step);
}
} catch (err) {
// Roll back in reverse order using compensations
for (const step of completed.reverse()) {
try {
await step.compensate();
} catch (compErr) {
// Send to dead-letter queue for manual intervention
await deadLetterQueue.publish({ step: step.name, error: compErr });
}
}
throw err;
}
}
await runSaga([
{ name: 'reserveInventory', action: () => inventoryClient.reserve(orderId), compensate: () => inventoryClient.release(orderId) },
{ name: 'chargePayment', action: () => paymentClient.charge(orderId), compensate: () => paymentClient.refund(orderId) },
{ name: 'scheduleShipment', action: () => shippingClient.schedule(orderId), compensate: () => shippingClient.cancel(orderId) },
]);Sagas trade atomicity for availability and scalability. Between steps, the system is in a real, observable intermediate state — for example, inventory reserved but payment not yet charged. Design your data model and UI to expose these intermediate states honestly (e.g., an order status of 'Payment Pending') rather than hiding them.
Common Pitfalls
Teams new to sagas often make a few recurring mistakes. First, forgetting that steps can fail out of order relative to compensations arriving — network retries mean a compensation message could theoretically arrive before its corresponding action is fully recorded, so idempotency keys and careful ordering (or using a per-saga correlation ID with a state machine) are essential. Second, treating semantic locks as optional: because there's no database-level lock across services, a saga in progress can leave inventory 'reserved' but visible to other processes unless the reservation itself is explicit business state, not just an in-flight assumption. Third, letting sagas grow too large — a saga spanning eight services with complex branching compensation logic becomes nearly impossible to reason about; it's often better to break it into smaller sagas with clear business boundaries, sometimes composing a saga of sagas.
Cricket analogy: Forgetting that a no-ball call can arrive after play has already continued for a ball or two is like a saga's out-of-order compensation risk, requiring the scorer to carefully reconcile the sequence rather than assume strict ordering.
A saga guarantees eventual consistency, not isolation. Other parts of your system can observe intermediate states mid-saga (e.g., an order that shows 'confirmed' before payment has actually cleared), which is very different from the isolation guarantee of a database transaction. Design read models and business rules with this explicitly in mind.
- Sagas replace distributed ACID transactions across services with a sequence of local transactions, each paired with a compensating action.
- Two-phase commit doesn't scale across microservices because it requires blocking locks held by a central coordinator across all participants.
- Choreography coordinates via events with no central controller, favoring decoupling; orchestration uses a central coordinator, favoring visibility and easier reasoning.
- Compensating transactions are new, auditable business operations that semantically undo a step, not raw database rollbacks.
- Compensations must be idempotent and retriable, with a dead-letter queue or manual-intervention path for when compensation itself fails.
- Sagas trade atomicity and isolation for availability; intermediate states are real and observable, and should be modeled explicitly, not hidden.
- Keep individual sagas small and scoped to a clear business capability; very large sagas with deep branching become unmanageable.
Practice what you learned
1. Why do microservices typically avoid two-phase commit (2PC) for cross-service transactions?
2. What is a compensating transaction?
3. In saga choreography, how do services coordinate?
4. What consistency guarantee does a saga provide, as opposed to isolation?
5. What should be done when a large saga spans many services with deeply branching compensation logic?
Was this page helpful?
You May Also Like
Database-per-Service Pattern
Each microservice owns and exclusively accesses its own database, preventing hidden coupling through shared schemas and letting teams evolve their data models independently.
Eventual Consistency Explained
Eventual consistency guarantees that, absent new updates, all replicas or downstream views of data will converge to the same state — but not instantly, which shapes how microservices must be designed.
The Outbox Pattern
The Outbox pattern guarantees a service's database write and its corresponding event publication happen atomically, by writing the event to an 'outbox' table in the same local transaction and relaying it separately.
CQRS Explained
Command Query Responsibility Segregation splits the write model and the read model of a service into separate paths, letting each be optimized, scaled, and evolved independently.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics