What is the Saga Pattern in Microservices?
Learn how the Saga pattern coordinates distributed transactions across microservices using local commits and compensating actions.
Expected Interview Answer
The Saga pattern manages a business transaction that spans multiple microservices by breaking it into a sequence of local transactions, where each step publishes an event or is invoked by an orchestrator, and every step has a matching compensating action to undo it if a later step fails.
Because microservices each own their own database, a single ACID transaction across all of them is impractical, so a saga instead commits each local step independently and immediately, then relies on compensation rather than rollback to handle failures. In choreography, each service listens for events and reacts, publishing its own event when done; in orchestration, a central saga coordinator explicitly tells each service what to do next and triggers compensations in reverse order if a step fails. The trade-off versus two-phase commit is that sagas give up strict atomicity and isolation for availability and loose coupling, so intermediate states are temporarily visible to other parts of the system.
- Avoids distributed locks and long-held resources across services
- Keeps each microservice autonomous with its own local database
- Scales better than 2PC under high load and network partitions
- Compensating actions handle partial failure without global blocking
AI Mentor Explanation
Think of organizing a multi-city cricket tour where each city independently books its own stadium, hotel, and transport as separate confirmed steps, rather than holding everything provisionally until the whole tour is locked in. If the third city's stadium booking later falls through, the tour organizer does not undo the first two cities' bookings instantly — instead it triggers a specific cancellation action for each already-confirmed city to unwind them one by one. The Saga pattern works the same way: each service commits its own step immediately, and failures trigger compensating actions rather than a single global rollback.
Step-by-Step Explanation
Step 1
Break the transaction into local steps
Identify each microservice-owned step (e.g. payment, inventory, shipping) that must complete for the overall business transaction.
Step 2
Execute and commit each step locally
Each service performs its own ACID transaction and commits immediately, then signals completion via an event or orchestrator call.
Step 3
Define a compensating action per step
Every step that can fail downstream needs a matching undo action (e.g. refund payment, release stock).
Step 4
Trigger compensations on failure
If any step fails, previously completed steps are compensated in reverse order to bring the system back to a consistent state.
What Interviewer Expects
- Clear distinction between choreography-based and orchestration-based sagas
- Understanding that sagas commit locally instead of holding a global lock
- Ability to design compensating transactions for a given workflow
- Awareness of the trade-off: eventual consistency and temporarily visible partial state
Common Mistakes
- Describing sagas as if they roll back atomically like a single database transaction
- Forgetting that compensations must be idempotent and safe to retry
- Not distinguishing orchestration (central coordinator) from choreography (event-driven)
- Ignoring that intermediate saga states are visible to other services before compensation completes
Best Answer (HR Friendly)
“The Saga pattern breaks a transaction that spans multiple services into a chain of smaller local transactions, each committed on its own. If a later step fails, instead of a single rollback, the system runs specific compensating actions, like a refund, to undo the earlier steps that already succeeded.”
Code Example
-- Step 1: Payment service (own database, own transaction)
BEGIN;
INSERT INTO Payments (order_id, amount, status) VALUES (501, 250.00, 'CHARGED');
COMMIT;
-- Step 2: Inventory service (own database, own transaction)
BEGIN;
UPDATE Inventory SET reserved = reserved + 1 WHERE sku = 'SKU-99';
COMMIT;
-- Step 3: Shipping service fails to schedule a courier.
-- Orchestrator triggers compensations in reverse order:
-- Compensate inventory
BEGIN;
UPDATE Inventory SET reserved = reserved - 1 WHERE sku = 'SKU-99';
COMMIT;
-- Compensate payment
BEGIN;
UPDATE Payments SET status = 'REFUNDED' WHERE order_id = 501;
COMMIT;Follow-up Questions
- How does choreography-based saga differ from orchestration-based saga?
- How do you make a compensating transaction idempotent?
- What isolation problems can occur while a saga is mid-flight?
- When would you choose 2PC over a saga, or vice versa?
MCQ Practice
1. What replaces a global rollback in the Saga pattern when a step fails?
Sagas commit each local step immediately, so failures are undone by running specific compensating actions for completed steps.
2. In an orchestration-based saga, who decides what each service should do next?
Orchestration uses a central coordinator that tells each participating service what step to run and when to compensate.
3. What consistency model does the Saga pattern typically provide across services?
Because each local transaction commits independently, other parts of the system can observe intermediate states before compensation completes.
Flash Cards
What is the Saga pattern? — A sequence of local transactions across services, each committed independently, with compensating actions to undo failures.
Choreography vs orchestration saga? — Choreography: services react to events independently. Orchestration: a central coordinator explicitly directs each step.
What is a compensating transaction? — An action that semantically undoes a previously committed local transaction, like issuing a refund.
Why use sagas instead of 2PC in microservices? — Sagas avoid holding distributed locks across services, trading strict atomicity for availability and loose coupling.