Saga: Orchestration vs Choreography

Saga: The Data-Consistency Mechanics taught you what a saga is: local commits, compensations held ready, the pivot deciding which way recovery runs. At the very end it named a fork, who runs the thing, gave each branch a paragraph, and moved on, because the mechanics were the lesson. The fork deserves more than a paragraph. Sooner or later it decides how your team spends its worst afternoons, and Event Sourcing closed on exactly this cliffhanger: when events can drive state, who tells the story, a conductor, or the band listening to itself?

Hold one concrete order in mind for the whole lesson. A customer clicks buy: the order service records it, payment must charge the card, inventory must reserve the goods, shipping must book the parcel. Four services, four databases, no shared transaction to hide behind, because Database per Service took that away on purpose. The steps are fixed. The compensations are written. The only open question is the one this lesson settles: who advances the story?

There are exactly two answers, and they produce systems that fail differently, debug differently, and rot differently. Most teams pick one by accident, by copying whichever blog post they read first. You are going to pick on purpose.

Orchestration gives the saga a home. One service, the orchestrator, holds an explicit state machine for every running order: created, awaiting stock, awaiting payment, awaiting shipping, done. It advances the story by sending commands, imperative messages addressed to someone: reserve 2 units for #123, charge card for #123. Each participant does its one job and sends a reply. The conductor reads the reply, updates the state machine, and issues the next command. When a step fails, the conductor consults the same state machine and issues the compensating commands in reverse, exactly the recovery the mechanics lesson defined, now with a definite author.

Notice the grammar. Event Sourcing taught you that events are past-tense facts addressed to no one. A command is the opposite creature: an instruction, addressed, refusable. Orchestration is built from commands and replies; the participants never need to know the flow exists. Payment knows how to charge cards. It does not know what an order is, what comes after payment, or that inventory exists. The knowledge of the sequence lives in one place, and only there.

Two worries surface immediately, and one of them dissolves under inspection. Extra hop? Real, and usually irrelevant: these are queue messages in a flow already measured in seconds. Single point of failure? Here is where the previous lesson pays off: serious orchestrators, Netflix's Conductor, Uber's Cadence and its successor Temporal, AWS Step Functions, persist every workflow as an event history and rebuild the state machine by replaying it. The conductor's brain is an event-sourced log. Kill the process mid-saga, restart it anywhere, replay, resume; the pattern you learned last lesson is literally what makes this pattern safe to run. A conductor is not a fragile boss. It is a replicated service whose memory survives it.

Choreography deletes the conductor and keeps the music. Each service publishes an event when its step completes, OrderPlaced, StockReserved, PaymentCaptured, and subscribes to the events that concern it. Inventory listens for OrderPlaced and reserves. Payment listens for StockReserved and charges. Shipping listens for PaymentCaptured and books. Nobody sends anyone an instruction; everybody announces what already happened and trusts whoever cares to care. The workflow is real, you just watched it complete, but it is written down nowhere. It is the sum of the subscriptions, the property the mechanics lesson called existing nowhere and everywhere.

What you buy is autonomy. No coordinator to build or operate. Any service can join the story without asking permission: analytics starts consuming PaymentCaptured tomorrow and nobody else deploys anything. Teams ship independently, the property microservices were bought for in the first place. For a story of two or three steps, this is genuinely the lighter design, and plenty of production order flows run this way for years, happily.

What you spend is legibility, and one hard dependency: the whole design leans on events being delivered. A choreographed saga has no conductor noticing that step three never happened; a dropped event is not an error anyone sees, it is silence. That is why Outbox + CDC: Reliable Events from Your Database sits directly upstream of this pattern, and why the mechanics lesson warned that a dropped event silently strands the saga. Choreography does not remove the need for reliability machinery; it makes that machinery the load-bearing wall.

Styles reveal themselves under failure, so walk the same failure through both. The card is declined after inventory already reserved the stock. Recovery, per the mechanics lesson, is two compensations: release the stock, cancel the order.

With a conductor: the declined reply lands at the hub. The state machine says this order sits at the charge step with stock already reserved, so compensation runs backward from there: release stock for #123, cancel order #123, two commands, issued in order, tracked to completion, retried if a participant is slow. One component decided, and the decision is sitting in its history when the postmortem asks what happened at 14:02.

Without one: payment publishes PaymentFailed and is done; it has no idea what should happen next, by design. The remedy is distributed across everyone who should care. Inventory releases the stock if it subscribed to PaymentFailed. Order cancels if it subscribed. Every compensation is a private reaction, and the saga is correct only if every service remembered to listen for every failure event that concerns it. Miss one subscription, and nothing crashes, nothing alerts: the stock simply stays reserved forever, and you find out when a customer asks why the last unit shows out of stock while nobody's order contains it.

That is the real asymmetry. Both styles run the same compensations on the happy sad-path. But orchestration makes recovery somebody's job, checked in one place, while choreography makes it everybody's promise, checked nowhere. Promises scattered across four repos are exactly the kind of thing that is true at launch and false eighteen months later.

The second revealing question is not a failure at all. Support pings: customer says they paid, nothing arrived, where is order #123?

With a conductor, that question has an address. Query the orchestrator: #123 · AWAITING_SHIPPING since 14:02 · stock ✓ 14:01 · payment ✓ 14:02 · shipping command sent, no reply. The full story, from one state machine, in one query, fresh. Tools like Temporal and Step Functions render exactly this as a console page, because when the workflow is explicit, showing it is trivial.

Without one, nobody holds that answer. The state exists, but it is smeared: order has a row, payment has a charge, inventory has a reservation, shipping has, apparently, nothing. Answering means collecting fragments from four services and lining up timestamps to infer that the StockReserved event was published but shipping never reacted. It is doable; teams build correlation IDs and tracing precisely for this. But notice what happened: with a conductor you read the workflow state; without one you reconstruct it, every single time, under support-ticket pressure. If that reconstruction happens weekly, its cost belongs in your choice of style, and this one question, who answers 'where is my order' and how fast, settles more real-world saga arguments than any architectural principle.

One order, both nervous systems, and this time you are the failure. Type a real amount and run the same purchase under a conductor and on the open bus; the card declines above its limit, or you can simply break a service mid-story and watch each style cope. The subscription panel is the trap the whole lesson has been warning you about: untick one listener before the sad path and see what silence looks like. When it all settles, ask both systems the support question, where is this order, and time the difference between reading an answer and reconstructing one.

Carry out one observation: the sad path succeeded in both styles only when every listener existed. The conductor made that a fact you could read; the bus made it a promise you had to test.

Both styles are healthy at birth. The judgment call is really about how each decays, because each rots along its own grain.

Orchestration rots inward. The hub is a gravity well: it already knows the sequence, so the next business rule, don't charge VIPs a deposit, retry shipping twice before refunding, lands there instead of in the service that owns the domain. Rule by rule the conductor swells into a god service and the participants go anemic, mere executors of someone else's brain. That is the old enterprise-service-bus disease wearing modern clothes, the smart-pipes smell the API Gateway & BFF lesson warned about at the edge. The defense is a boundary you enforce in review: the conductor owns sequence, timeouts, and compensation order, and precisely nothing else. Payment logic lives in payment, forever.

Choreography rots outward. Nobody owns the flow, so nobody notices it growing. Each new requirement adds one small, locally-reasonable subscription, and the sum quietly becomes a web nobody can draw from memory. Coupling did not disappear when the conductor left, it went underground, into event schemas and implicit ordering, invisible until the day a change in one publisher breaks three subscribers the author never heard of. The end state has a name among veterans, event spaghetti, and its signature dish is the cycle: service A's event triggers B, B's triggers C, and C's arrives back at A, which reacts again. The defense is honesty about scale: keep choreographed chains short, keep a drawn map of the subscriptions in the repo, and when the map stops fitting on one screen, admit the workflow has grown up and give it a conductor.

Neither decay is destiny. Both are what happens by default, which is exactly why the choice deserves to be made on purpose.

The choice is per workflow, never per company, and a short rubric covers almost every real case.

Reach for a conductor when any of these is true: the story has four or more steps; the flow itself is a business entity someone owns (there is a person whose job title effectively includes 'the checkout'); the sequence changes often enough that editing one state machine beats coordinating deploys across repos; or support must answer 'where is my order' on a clock. Long-running flows with humans in the loop, approvals, refunds, KYC, are conductor territory almost by definition, and this is why the durable-execution tools exist as a product category.

Let events carry it when the story is two or three steps and stable; when the 'workflow' is really just announcements, things that happened that others may care about, with no sequence to guard; or when the reactors belong to other teams and other bounded contexts entirely, where a conductor would be one team reaching into another's autonomy.

Which points at the truth mature systems converge on. It is not a compromise between the styles; it is a division of labor: orchestrate within the use case, choreograph between use cases. The checkout saga, order, payment, inventory, shipping, runs under a conductor, because it is one business action with a sequence, an owner, and a support clock. Then the finished fact, OrderCompleted, is published to the world, and analytics, email, loyalty, recommendations react in pure choreography, because an announcement has no sequence, no compensation, and no conductor's business. Commands inside the boundary, events across it. Draw that line deliberately and both styles stay in the region where they are strong.

• The fork is about authorship, not mechanics. Steps and compensations are identical in both styles, the mechanics lesson's material unchanged; the only question is who advances the story: a conductor sending addressed commands, or autonomous services reacting to past-tense events.

• Orchestration buys legibility. One state machine holds the flow, so recovery is somebody's job and 'where is #123' is a query. The conductor is no single point of failure when its memory is an event-sourced history, replayed on restart, Event Sourcing running inside Temporal, Conductor, and Step Functions.

• Choreography buys autonomy. No hub to run, and new reactors join without anyone's permission. The bill: the workflow is the sum of subscriptions, recovery is everybody's promise, and a missed listener fails silently, which makes Outbox + CDC: Reliable Events from Your Database the load-bearing wall.

• Each style rots along its own grain. Conductors swell into god services over anemic participants unless the hub is held to sequence-only; event webs grow spaghetti and cycles unless chains stay short and mapped. Both decays are the default, not the exception.

• Choose per workflow, then divide the labor. Four-plus steps, an owned flow, a changing sequence, a support clock: conduct. Two or three stable steps or pure announcements: choreograph. The mature answer is both at once: orchestrate within the use case, choreograph between use cases, commands inside the boundary, events across it.

This closes the pattern arc. Across this section you found services (Service Discovery), guarded the door (API Gateway & BFF), moved the plumbing out of the code (Sidecar & Service Mesh), moved the settings out of the build (Externalized Configuration), escaped the old system (Strangler Fig & Anti-Corruption Layer), gave every service its own data (Database per Service), split reads from writes (CQRS), made the log the truth (Event Sourcing), and now put the multi-service story under a chosen author. The Checkpoint: Microservices Patterns asks you to use all nine at once, the way an architecture review would.