Distributed systems
Orchestration vs choreography
Short answer
Choose orchestration when a business workflow needs one visible owner, explicit branching, and compensations. Choose choreography for simple event reactions owned by independent services; once a workflow has many steps or hidden dependencies, centralising its state is usually safer than making operators reconstruct it from events.
Written and reviewed by Sahil Srivastav
What each one actually is
An orchestrator owns the workflow state and calls participants or sends commands. It can show the next step, deadline, retry policy, and compensation in one place.
In choreography, services subscribe to events and decide their own reactions. There is no central coordinator, so coupling is reduced at the interface but the overall workflow is spread across consumers.
Both are ways to implement a saga: neither provides a distributed ACID transaction. Every step needs an idempotency key and a recovery story.
Side by side
| Orchestration | Choreography | |
|---|---|---|
| Workflow visibility | One state machine is inspectable | Must correlate events across services |
| Coupling | Coordinator knows participant contracts | Consumers depend on event semantics |
| Adding a step | Change one workflow definition | Add a subscriber, but discover all side effects |
| Branching | Explicit conditions and timeouts | Emerges from event reactions |
| Failure recovery | Central compensation and retry policy | Each service owns recovery for its reaction |
| Operational risk | Coordinator can become a bottleneck | Hidden cycles and duplicate reactions |
| Team autonomy | Central workflow ownership | Teams own event consumers independently |
| Testing | State-machine and contract tests | Event contracts plus end-to-end scenarios |
Choose Orchestration when
- A payment, reservation, or fulfilment flow has ordered steps and compensation
- Operators need one place to see and resume a stuck workflow
- Timeouts and human approval are explicit parts of the process
- A single team owns the business process
Choose Choreography when
- Events are independent notifications with simple reactions
- Services should react without knowing the full workflow
- The event contract is stable and consumers can evolve independently
- Central workflow ownership would be artificial or too tightly coupled
The trade-off in detail
Choreography looks decoupled until nobody knows who emits the event that drives a side effect. Maintain an event catalogue, ownership, correlation IDs, and a way to replay safely; otherwise debugging becomes archaeology.
An orchestrator is not automatically a synchronous bottleneck. It can persist state and issue commands asynchronously, but it becomes a critical dependency and must be made highly available and idempotent.
Compensations are new business actions, not database rollbacks. A refund, release, or cancellation can itself fail, so model it as a state transition with retries and operator visibility.
Things that are commonly said and are wrong
- “Choreography has no coupling.” Consumers are coupled to event names, fields, ordering, and meaning.
- “Orchestration means one giant service.” A focused workflow component can own coordination while participants own their data.
- “A saga guarantees consistency.” It provides a path to convergence through compensating actions, not atomic isolation.
FAQ
Which is easier to operate?
Orchestration usually is once a workflow has several steps, because state and retries are visible together. Choreography is easy for small independent reactions but needs strong event observability as it grows.
Can a system use both?
Yes. An order saga may be orchestrated, while independent analytics and notifications subscribe to the resulting events. Keep commands and facts distinct so consumers do not accidentally become workflow owners.
Where should saga state live?
In durable storage owned by the orchestrator, keyed by a correlation or business ID. Memory-only coordination loses progress on restart and makes recovery depend on guessing.