We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
6 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Distributed Systems Core
Free preview: the first 2 parts of this 13-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Distributed Systems Core
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You're booking a vacation. You need a flight, a hotel, and a rental car. Three different companies, three different systems. You don't want the flight without the hotel, and you don't want the hotel without the car. It's all or nothing.
In a perfect world, you'd wrap all three bookings in a single transaction. But there's no shared database between Delta, Marriott, and Hertz. You can't lock a row in Delta's flight database while you wait for Hertz to confirm a car. These are independent systems with independent databases.
So what do you do? You book the flight. Then the hotel. Then the car. If the car isn't available, you cancel the hotel. Then cancel the flight. Each step moves forward, and each step has a corresponding "undo" action. This is a saga.
Hector Garcia-Molina and Kenneth Salem introduced the saga pattern in 1987 as an alternative to long-lived transactions that hold locks for extended periods. The original context was single-database transactions that took minutes or hours (think: batch processing). But the pattern found its true calling in architecture, where distributed transactions across services are impractical.
Today, every serious microservices architecture uses sagas. Uber's ride-matching, Netflix's content delivery pipeline, Amazon's order fulfillment, they're all sagas. Understanding the pattern deeply, including its two coordination styles, its failure modes, and its consistency implications, is essential for any engineer building distributed systems.
A saga is a sequence of local transactions. Each local transaction updates one service's database and publishes an event or calls the next step. If any step fails, previously completed steps are "compensated", undone by executing a compensating transaction.
Forward recovery, if a step fails but can be retried (transient failure), retry it. Move forward.
Backward recovery, if a step fails and can't be retried (business rule violation), execute compensating transactions for all previously completed steps. Move backward.
| Step | Action | Compensating Action |
|---|---|---|
| 1. Create Order | Insert order record, status: PENDING | Delete order or set status: CANCELLED |
| 2. Reserve Inventory | Decrement stock count | Increment stock count |
| 3. Process Payment | Charge credit card | Refund credit card |
| 4. Ship Order | Create shipping label | Cancel shipment |
Critical insight: Compensating transactions are not rollbacks. A database rollback erases the change as if it never happened. A compensating transaction creates a new transaction that semantically reverses the effect. The original transaction happened, it's in the logs, it's in the audit trail. The compensation is a separate event that undoes its business effect.
This distinction matters. A credit card charge followed by a refund is not the same as "the charge never happened." The customer sees both on their statement. The merchant pays processing fees on both. The audit trail shows both. This is why sagas provide "eventual consistency" rather than atomicity, intermediate states are visible to the outside world.
The three types of saga steps:
| Type | Description | Can Be Compensated? |
|---|---|---|
| Compensatable | Can be undone by a compensating transaction | Yes |
| Pivot | The go/no-go decision point. If it succeeds, the saga commits | It's the decision point |
| Retriable | Guaranteed to eventually succeed (with retries) | No need, it will succeed |
The pattern is: compensatable steps, then the pivot, then retriable steps. If anything before the pivot fails, compensate backward. If anything after the pivot fails, retry forward.