We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A saga implementation where a central orchestrator tells each service what step to execute next. Easier to debug than choreography but creates a single point of coordination.
In short
Saga orchestration is a pattern for managing a distributed transaction across microservices using a central coordinator (the orchestrator) that calls each service one step at a time and, if any step fails, invokes compensating actions to undo the steps that already succeeded. It trades a single point of coordination for clear, centralized control over the workflow and its rollback logic.
In short
Saga orchestration is a pattern for managing a distributed transaction across microservices using a central coordinator (the orchestrator) that calls each service one step at a time and, if any step fails, invokes compensating actions to undo the steps that already succeeded. It trades a single point of coordination for clear, centralized control over the workflow and its rollback logic.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Saga Orchestration across a run of lessons, not one page. These 4 alone are about 120 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
Long-lived transactions without distributed locking, orchestration vs choreography for microservices.
Two fundamentally different ways to coordinate microservices: decentralized dance vs. centralized conductor.
Coordinating atomic operations across multiple nodes, the hardest problem in databases.
When network calls fail, and they will, retries turn transient failures into invisible hiccups.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Saga Patternpay once,
yours for life
When a business operation spans several microservices, you cannot wrap it in one database transaction because each service owns its own database. A saga solves this by breaking the operation into a sequence of local transactions, one per service, where each local transaction is paired with a compensating transaction that reverses it if something later goes wrong.
There are two ways to run a saga: choreography and orchestration. In choreography, services react to each other's events with no central brain. In orchestration, a dedicated component called the orchestrator owns the workflow. It knows the full sequence of steps, calls each service in turn, waits for the result, and decides what to do next.
The orchestrator is the saga's state machine. It tracks where the saga is, which steps have completed, and which compensations need to run on failure. Because all of that logic lives in one place, you can read the entire business flow in a single file instead of tracing it across a dozen event handlers.
Take an order-checkout saga with three steps: reserve inventory, charge payment, schedule shipping. The orchestrator sends a command to the Inventory service. Inventory commits its local transaction and replies success. The orchestrator records that step as done and sends a command to the Payment service.
If Payment fails, the orchestrator does not just stop. It walks backward through the steps that already succeeded and issues compensating commands: release the reserved inventory. Each compensation is its own local transaction, so the system reaches a consistent state even though no global rollback exists. This is why sagas give eventual consistency, not the atomic all-or-nothing of a single ACID transaction.
The orchestrator persists its own state after every step, usually in a database table or an event log, so a crash mid-saga can be recovered. Commands and replies typically travel over a message broker such as Kafka or RabbitMQ rather than synchronous HTTP, which lets the orchestrator survive a service being temporarily down and retry. Compensating actions must be idempotent because retries can deliver the same command twice.
Reach for orchestration when a workflow has many steps, real branching logic, or complex rollback rules, and when you need to see and debug the whole flow in one place. Order processing, travel booking, and loan approval are classic fits because the sequence and the failure handling are genuinely complicated.
The cost is a single point of coordination. The orchestrator becomes a service every step depends on, so it must be highly available and is one more thing to deploy, scale, and monitor. It can also drift toward becoming a fat god-service that knows too much business logic if you are not disciplined about keeping the step logic inside each service.
Choreography is the better choice when a flow has only two or three steps and the services are loosely coupled, because it avoids the extra component entirely. The general rule teams use: start with choreography for simple flows, switch to orchestration once the number of steps and failure paths makes the event web hard to follow.
Camunda and Temporal are workflow engines built specifically to act as saga orchestrators. In Temporal, you write the saga as ordinary code: a workflow function calls activities for reserve inventory, charge payment, and ship, and registers a compensation for each. Temporal persists every step, so if the worker crashes after charging payment, it resumes from its recorded history and does not rerun a step that already finished, though the charge activity should still be idempotent because an activity cut off mid-call is retried.
AWS Step Functions plays the same role on AWS. You define the order workflow as a state machine in JSON, each state invoking a Lambda or service, with catch blocks that route to compensating states on failure. Step Functions stores the execution history, giving you a visual timeline of which steps ran and where a saga failed, which is the main reason teams pick orchestration over choreography in the first place.
Temporal
Durable workflow engine where you write sagas as code; persists every step so a crashed orchestrator resumes without re-running completed work or running compensations twice.
AWS Step Functions
Serverless state machine that orchestrates Lambda and service calls with catch blocks for compensation, plus a visual execution history for debugging failed sagas.
Camunda
BPMN-based workflow engine widely used to model order, payment, and approval sagas where a central orchestrator drives each service and handles rollback.
Netflix Conductor
Open-source orchestrator Netflix built to coordinate long-running multi-service workflows such as content ingestion and encoding pipelines.
In orchestration, a central component calls each service in sequence and decides the next step and any compensations. In choreography, there is no central brain; each service reacts to events emitted by others. Orchestration is easier to debug and reason about; choreography has fewer moving parts and looser coupling.
No. It gives eventual consistency. There is no global rollback. Each step is its own local transaction, and failures are handled by running compensating transactions that undo earlier steps. The system can briefly be in a partial state before compensation completes.
It is an operation that semantically undoes a completed step. If a step reserved inventory, its compensation releases that inventory. Compensations rarely restore the exact prior state; they reverse the business effect, and they should be idempotent because they may be retried.
It is a single point of coordination, which is why production orchestrators persist their state and run with redundancy. Engines like Temporal and AWS Step Functions store execution history so a crashed orchestrator resumes mid-saga rather than losing progress.
Choose orchestration when the workflow has many steps, branching logic, or complicated rollback rules, and when you need to see and trace the whole flow in one place. Stick with choreography for short, simple flows of two or three loosely coupled steps.
Saga Pattern
A way to manage distributed transactions across microservices using a sequence of local transactions with compensating actions for rollback.
Saga Choreography
A saga implementation where each service listens for events and decides what to do next independently. No central coordinator. Looser coupling but harder to trace.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
Circuit Breaker
A pattern that stops calling a failing service after repeated failures, preventing cascade failures. Like an electrical circuit breaker that cuts power to prevent fires.
This page explains the idea. The "Saga Pattern" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Saga Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Saga Orchestration in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
