What is the saga pattern for distributed transactions?
40 views
56 of 106
1
The problem
Question presented to candidate:
"Placing an order touches three services, each with its own database: inventory, payments and shipping. We cannot use one database transaction across them. Explain the saga pattern, how it undoes work when a later step fails, and what guarantees you lose compared with a normal ACID transaction."
What a strong answer should cover:
A saga is a sequence of local transactions, one per service, each with a compensating transaction that semantically undoes it; on failure, the compensations of the completed steps run in reverse order
Orchestration (a central coordinator tells each service what to do and keeps a saga log) vs choreography (services react to each other events) and when each fits
Steps and compensations must be idempotent and retryable, because messages are delivered at least once and the coordinator can crash; a compensation must eventually succeed
Sagas give atomicity in the end (all steps or all compensations) and durability, but no isolation: other requests see intermediate states โ dirty reads and lost updates are possible
Countermeasures: semantic locks (a PENDING status), commutative updates, putting the riskiest or irreversible step last (pivot transaction), rereading values
Each step should publish its event reliably, usually via the transactional outbox
Clarifying questions expected:
Which steps cannot be undone (an email sent, goods shipped), so they can be placed last?
Is a few seconds of visible intermediate state acceptable to the business, for example stock that looks reserved and later reappears?
Code / implementation expected: Optional โ a clear explanation of steps and compensations; the example runs an orchestrated saga through failures, retries and a crash.
saga
transactions
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Developers who build or interview for microservice back ends. You know what a database transaction is; no distributed-systems background assumed.
Difficulty: Medium
Verified with: Node 22.22 and Python 3.12 (both print identical output).
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the exact words an interviewer expects. All behaviour shown comes from running the example; the Verified section quotes the full output.
1. Why This Even Matters โ A Story First
You plan a trip: book a flight, then a hotel, then a rental car. Each booking is its own website with its own confirmation. No travel agent can make the three websites commit "all or nothing" together. So you do the sensible thing: book them one at a time, and if the car is unavailable, you **cancel the hotel a
The solution is hidden so you can try first
13 min read ยท 11 sections
4
Read the code
Orchestrated order saga: compensations in reverse, retried refunds, idempotent replay and the isolation gap