Choreography versus orchestration

Should each step know what comes next, or should one place know the whole plan?

An order has to be paid for, then stocked, then shipped, then confirmed. Four services, one sequence. Where should the knowledge of that sequence live?

There are only two honest answers. Either each service knows what it should trigger when it finishes — payment announces that it is done, and stock hears that and acts — or one component holds the whole plan and calls the four in turn. Both work. Both ship real systems. So the interesting question is not which is correct, but what each one is actually buying, and what it quietly gives up in exchange.

Begin with something easy to overlook: the sequence is a fact. Somebody or something has to hold it. It does not disappear when you distribute it; it only gets spread out. So the real choice is between keeping that fact in one place and scattering it across four.

Consider the scattered version — choreography. Payment finishes and publishes an event: payment taken. It does not know or care who listens. Stock happens to subscribe, reserves the item, and publishes stock reserved. Shipping subscribes to that. Nobody was called; everybody reacted.

What did that buy? Adding a fifth participant is now a matter of subscribing to an existing event and changing nothing that already runs. Loyalty points want to be awarded on payment? Subscribe. No existing service is edited, redeployed, or even told. That is a real and substantial property, and it is why choreography feels so good early on.

Now ask the awkward question: where is the process? Open any single service and you will find one step and a publish statement. The order of the four exists nowhere as an artefact — it is an emergent consequence of who happens to subscribe to what. To answer "what happens after payment?" you must inspect every subscriber list in the estate. To answer "why did order 4821 stop?" you must reconstruct its path from logs across four systems. Practitioners have a name for the failure mode this becomes at scale, and the honest version is not that choreography is wrong but that nobody owns the process, so nobody can see it, test it, or change it deliberately.

Turn to the other arrangement — orchestration. A single component holds the sequence explicitly: take payment, then reserve stock, then ship, then confirm. It calls each service and waits for the answer. The participants become simpler, because none of them knows what comes next; they take a request and return a result.

And now the process is a thing you can look at. It is a piece of code, or a definition, in one file. You can read it, diff it, version it, and ask an engine which step each in-flight order is on. When payment succeeds but shipping fails, the compensating action — refund the payment — has an obvious home, because one component knows that both happened and in what order. Under choreography, compensation is much harder: the service that must undo work is not the service that knows the overall attempt has failed, so the rollback has to be choreographed too, event by event.

What is the cost, then? Coupling of a particular kind. The orchestrator knows about all four participants. Every change to the process touches it. It is a place where a large amount of business logic accretes, and if it is written carelessly it becomes exactly the thing microservices were meant to escape — a central component that must be redeployed for any change anywhere.

Notice, though, that the two costs are not the same kind of cost. Orchestration concentrates coupling somewhere visible and nameable. Choreography does not remove the coupling; it makes it implicit. Payment and stock are still coupled — stock will break if payment's event shape changes — but the coupling now lives in a subscription no one is looking at. Is a dependency you can see worse than one you cannot?

One caution against false tidiness. Real systems are rarely purely one or the other, and the sensible boundary is about transactional meaning: steps that must succeed or be compensated together form a process and want an owner, whereas notifying interested parties wants events. One estate happily runs an orchestrated checkout that publishes an order completed event a dozen unrelated services choreograph around.

Three clarifications.

First, this is not centralised versus decentralised computing. An orchestrator is one logical holder of a process, not one machine and not one per estate; a large system typically has many orchestrated workflows, each owning its own sequence. Concentrating the plan is not concentrating the work.

Second, the common misconception is that choreography is more loosely coupled by nature. It is more loosely coupled at the call level — nobody addresses anybody — and equally coupled at the contract level, since every subscriber depends on an event's shape and meaning. What choreography really removes is the need for the publisher to know its consumers.

Third, the choice reverses more easily in one direction. Extracting a process from a choreographed estate means discovering it first, and that discovery is the hard part; loosening an orchestrated process by publishing events from it is easy, because the process was already written down.

• How compensation is arranged in a choreographed estate, and why sagas come up alongside this choice.
• Whether an event schema is a looser contract than a function signature, or merely a less visible one.
• What it takes to recover a lost process definition from an estate that has only subscriptions.

Every term the collection defines is gathered in the glossary.