Saga Orchestration
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.
What is Saga Orchestration?
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.
What it is
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.
How it works under the hood
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.
When to use it and the trade-offs
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.
A concrete example
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 exactly where it left off and never double-charges.
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.
Where it is used in production
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.
Frequently asked questions
- What is the difference between saga orchestration and choreography?
- 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.
- Does saga orchestration give ACID transactions across services?
- 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.
- What is a compensating transaction?
- 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.
- Is the orchestrator a single point of failure?
- 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.
- When should I choose orchestration over choreography?
- 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.
Learn Saga Orchestration hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
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.