Orchestration versus choreography

What is orchestration versus choreography?

Orchestration and choreography are the two ways to coordinate work that runs across several systems. With orchestration, one component holds the process. It calls each participant in turn, records where the case is, and decides what happens next. With choreography, nobody holds the process. Each component announces what it just did, and the others react to those announcements on their own.

Chris Richardson puts each side in one sentence in his saga pattern catalogue. In choreography, each local transaction publishes domain events that trigger local transactions in other services. In orchestration, an orchestrator tells the participants what local transactions to execute.

Camunda frames the same split by the kind of message that travels. Choreography sends events, and the sender does not know who picks up the event or what happens next. Orchestration sends commands, because the sender wants something specific to happen. This is not a technology choice: you can build either style on the same message broker. It is a decision about where the knowledge of the end-to-end flow lives.

The same order process, drawn both ways

Take a webshop order that has to pass stock, payment and shipping. Three services, one business result.

Orchestrated. An order service starts a process instance and drives it. It sends a reserve-stock command to inventory and waits for the reply, then a charge command to payment, then a ship command to shipping, and marks the order confirmed. The route is written down in one place, in code or in a BPMN diagram, and the current step of order 4471 is a field in the orchestrator's own database.

Choreographed. The order service publishes order.placed and stops caring. Inventory hears it, reserves the stock, publishes stock.reserved. Payment hears that, charges the card, publishes payment.taken. Shipping hears that and books the courier. Four events, no commands, and no component that knows the route. The route exists only as the sum of who happens to subscribe to what.

Now the customer phones. Where is my order?

In the orchestrated version you open the process instance and read the answer. Camunda Operate, for one, shows the process diagram with the instance's current progress on it, its variables, and any incident that stopped it. Order 4471 has been parked on the payment step with a declined-card incident since 9:12. One lookup, one sentence to the customer.

In the choreographed version there is no instance to open. You filter every service's logs on the correlation id and read the trail: order published at 9:07, stock reserved at 9:08, payment logged a decline at 9:12, shipping never heard anything. Same answer, five systems and a distributed trace later, and only if somebody stamped a correlation id on every event long before this call came in.

Who knows the state of the whole process?

That phone call is the dimension the comparison turns on.

Orchestration gives you one place that knows. One place to read the status of a case, one place to change the flow when the business changes it, one place to look when something breaks. Emily Fortuna of Temporal states the debugging half plainly: because orchestration centralises control flow, debugging and understanding control flow is much simpler. Retries, timers and compensation live there too, which is why the saga pattern so often ends up orchestrated.

What orchestration costs is a component everything leans on. Microsoft's guidance on the choreography pattern names the bill: adding or removing a service can break existing logic because you have to rewire part of the communication path, and under load the orchestrator becomes a performance bottleneck and a single point of failure whose failure propagates to everything downstream.

Choreography gives you loose coupling. A new consumer can start listening to order.placed without anyone touching the order service, which is what you want when another team owns that consumer and ships on its own schedule.

What choreography costs is the answer to the phone call. Microsoft says it without hedging: without a central orchestrator holding the full transaction state, no single component has a complete view of an in-flight business operation, and you have to use distributed tracing and correlation identifiers consistently to keep any observability at all. Fortuna makes the same point from the code side: reading one service's codebase tells you nothing about the order the system should follow, because that ordering is spread across every service. Sequence is the cost that arrives later, since the pattern suits independent operations running in parallel and gets awkward as soon as service D may only start once B and C have both finished.

Where the line usually sits

For a company with one development team and a support desk that has to answer customers, orchestration is almost always the right default. Not because it is architecturally superior, but because the question you get asked twenty times a day is where a case is. The loose coupling choreography buys pays off when separate teams need to deploy without talking to each other. With one team, you are paying for a benefit you cannot spend.

Most systems that run a few years land in the same compromise, and Camunda and Microsoft describe it the same way: orchestrate inside a domain, choreograph between domains. Microsoft's version is to use choreography where communication across domain boundaries needs loose coupling, and to consider an orchestrator inside a single bounded context. Camunda's is to use events when the message leaves the context of the current domain, and orchestration when you are facing domain coupling between your services.

So the order process above stays orchestrated end to end, and when it finishes it publishes one order.completed event that reporting, marketing and the loyalty programme each pick up without ever appearing in the order flow. Fortuna adds a warning about timing: choreography looks lighter at the start, but orchestration is easier to build when you use it from the beginning. Retrofitting a central flow onto services that already assume nobody is in charge is the expensive version.

The same argument, now with AI agents

Multi-agent systems have reinvented this argument with new vocabulary. An orchestrator agent that plans the work and calls subagents is orchestration. A set of agents that hand control to each other, each deciding when to pass the task on, is choreography wearing a badge that says handoff.

Microsoft's catalogue of agent orchestration patterns lines up point for point. The manager-led patterns give you a plan and an audit trail of it. The handoff pattern gives you agents that decide among themselves when to transfer control, and the things to watch for there are infinite handoff loops and unpredictable routing paths, which is the agent-shaped version of an event cycle. Their advice on where to start is blunt: a single agent with tools is often the right default for enterprise use cases, and it is simpler to debug and test than a multi-agent setup.

One thing does change, and it changes in orchestration's favour. Agents are non-deterministic, so the same input can take a different route tomorrow. Microsoft's answer is to test agent workflows with scoring rubrics or a model as judge rather than exact-match assertions, and to instrument every agent operation and every handoff. When the path itself is not reproducible, a component that recorded which agent got which assignment and what came back is the only reason you can reconstruct what happened. The auditability argument that is merely convenient for services becomes load-bearing for agents.

What to watch out for with each style

The orchestrator that ate the business logic. Orchestration goes wrong when the central process slowly absorbs every rule, every exception and every special case for one customer, until nobody dares change it and every team queues behind it. The orchestrator should hold the route, the state and the error handling. The moment it starts holding pricing rules and VAT logic, split it.

The orchestrator as single point of failure. If it is down, nothing moves. Persist the state of every instance, make participants idempotent so a retry after a crash cannot charge a card twice, and run the engine so it survives losing a node.

Event storms and cycles. Microsoft describes decentralised event topologies producing emergent behaviour at scale, where a minor event triggers a cascade and services reacting to each other create feedback loops. The guardrails they name are event filtering, concurrency limits, throttling and explicit rules about what may react to what. Camunda names the milder daily version: event chains that nobody drew, that are not visible anywhere, and that make troubleshooting harder than it should be.

Nobody drew it, so nobody can change it. The quiet cost of choreography is that the process exists only in people's heads. Before you accept that, ask who in the company can currently draw the order flow on a whiteboard, and what happens the week that person leaves.