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 each service listens for events and decides what to do next independently. No central coordinator. Looser coupling but harder to trace.
In short
Saga choreography is a way to manage a distributed transaction across microservices where each service does its local work, publishes an event, and the next service reacts to that event on its own. There is no central coordinator. Services agree on the flow only through the events they emit and subscribe to.
In short
Saga choreography is a way to manage a distributed transaction across microservices where each service does its local work, publishes an event, and the next service reacts to that event on its own. There is no central coordinator. Services agree on the flow only through the events they emit and subscribe to.
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 Choreography across a run of lessons, not one page. These 4 alone are about 118 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.
A central channel where components publish and subscribe to events without knowing each other.
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
A saga is a sequence of local transactions that together make up one business operation spanning several services, like placing an order that touches Orders, Payments, Inventory, and Shipping. Each step commits to its own database. There is no shared database transaction and no two-phase commit, so the saga keeps consistency by running compensating actions when a later step fails.
Choreography is one of the two ways to run a saga. The other is orchestration, where a single coordinator tells each service what to do. In choreography there is no coordinator. Each service listens for events on a message bus, does its part, and publishes a new event that some other service is waiting for. The workflow is an emergent property of who subscribes to what.
The short version: orchestration is a conductor telling musicians when to play, choreography is dancers who each know their cue from the dancer next to them.
It runs on an event broker such as Kafka, RabbitMQ, or AWS SNS plus SQS. The first service commits its local transaction and publishes a domain event, for example OrderCreated. Payments subscribes to OrderCreated, charges the card, and publishes PaymentCompleted. Inventory subscribes to PaymentCompleted, reserves stock, and publishes StockReserved, and so on down the chain.
Failures are handled by compensating events flowing backward. If Inventory cannot reserve stock it publishes StockReservationFailed. Payments subscribes to that and issues a refund, then publishes PaymentRefunded, which the Orders service uses to mark the order canceled. Each service owns both its forward action and its undo action.
Two properties make this safe in practice. Events must be delivered reliably, usually with the transactional outbox pattern so the database write and the event publish cannot diverge. And every handler must be idempotent, because at-least-once brokers will redeliver, so charging the same OrderCreated twice has to be a no-op the second time. Correlation IDs on every event let you stitch the steps back together for debugging.
Choreography fits short sagas with a small number of participants, maybe two to four services, where the flow is simple and unlikely to grow complicated. Because there is no central service to deploy and own, it keeps services loosely coupled and each team can change its own logic without coordinating with a workflow owner.
The cost is that nobody can see the whole flow in one place. The business process is spread across the subscriptions of every service, so understanding what happens after OrderCreated means tracing events through five codebases. Cyclic dependencies sneak in easily, and a small change to one event can break a downstream service that you forgot subscribes to it.
Switch to orchestration once the saga has many steps, branching logic, or timeouts and retries you want to manage centrally. A common rule of thumb: use choreography while the flow stays linear and simple, move to an orchestrator like Temporal, AWS Step Functions, or a dedicated saga service once you need to ask one component what state the transaction is in.
Picture an e-commerce checkout. The Order service writes the order as PENDING and publishes OrderCreated to a Kafka topic. The Payment service consumes it, charges the customer through Stripe, and publishes PaymentCompleted. The Inventory service consumes that, decrements stock, and publishes StockReserved. Finally the Shipping service consumes StockReserved and schedules a courier, publishing OrderConfirmed, which flips the order to CONFIRMED.
Now suppose inventory is out of stock. Inventory publishes StockReservationFailed instead. Payment hears it and refunds the Stripe charge, publishing PaymentRefunded. Order hears that and moves the order to CANCELED. The customer is made whole without any single service having known the full plan in advance. Each one only knew its own cue.
Apache Kafka
The most common backbone for choreographed sagas, with each service consuming and producing domain events on topics.
Netflix
Uses event-driven choreography across services for workflows like content onboarding, with services reacting to each other's events rather than a single controller.
AWS (SNS + SQS)
A standard serverless setup where Lambda functions subscribe to topics and queues to react to events and emit the next step of a saga.
RabbitMQ
Used as the broker for choreographed sagas in many enterprise systems, routing events between services through exchanges and queues.
In orchestration a single coordinator service tells each participant what to do and tracks the overall state. In choreography there is no coordinator: each service reacts to events and publishes its own, so the flow is distributed across all participants. Orchestration is easier to monitor, choreography is more loosely coupled.
Through compensating actions. When a step fails it publishes a failure event, and the services that ran earlier steps subscribe to it and undo their work, for example refunding a payment or releasing reserved stock. The undo events flow backward through the chain until the saga is fully rolled back.
Most message brokers deliver at least once, so the same event can be redelivered. If charging a card or reserving stock ran twice it would corrupt state, so each handler must detect a duplicate, often by recording the processed event or correlation ID, and treat the repeat as a no-op.
Avoid it when the saga has many participants, branching logic, or timeouts you need to manage centrally. As the number of event subscriptions grows the flow becomes hard to follow and cyclic dependencies appear. At that point an orchestrator gives you one place to see and control the transaction.
No. That is the whole point of the saga pattern. Each service commits only its own local transaction, and global consistency is reached eventually through events and compensations rather than locking resources across services with two-phase commit.
Saga Pattern
A way to manage distributed transactions across microservices using a sequence of local transactions with compensating actions for rollback.
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.
Event-Driven Architecture
A design pattern where services communicate by producing and consuming events rather than making direct calls. Promotes loose coupling and asynchronous processing.
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.
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 Choreography 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.
