A workflow spans eight services using event choreography. Nobody can answer "where is order 41,229 stuck?". What do you change?
Show the full answer Hide the answer
What is being tested
Whether you recognise the specific threshold at which choreography stops being viable.
The diagnosis
The flow exists nowhere. In choreography, each service reacts to the previous one's event, so the overall sequence is an emergent property — documented nowhere, visible nowhere, and reconstructible only by correlating logs across eight services.
That is tolerable at three steps. At eight it means:
- Support cannot answer a customer's question.
- Nobody can add a step without understanding a sequence nobody can see.
- A stuck workflow is invisible — there is no component whose job it is to notice that step five never happened.
- Testing the whole flow requires all eight services.
What to change: introduce an orchestrator
A coordinator holds the state machine explicitly and issues commands. The flow is in one place: inspectable, testable, and answerable.
What that gives you:
- "Where is order 41,229?" becomes a query.
- Timeouts per step with a defined expiry action, so a step that never answers is detected — which is far more common than a step that fails.
- Compensation ordered deliberately, with irreversible steps last.
- A terminal state when compensation itself fails, which alerts a human rather than leaving the entity half-completed.
What it costs
A component to build, own and keep available. That cost is real and it is almost always smaller than an unmappable flow — and it is the trade that public accounts of large service estates consistently report making as step counts grew.
Keeping the benefits of events
Orchestration does not mean synchronous. The orchestrator can issue commands over a queue and react to events; services remain decoupled from each other while the sequence is explicit.
That is the distinction: choreography removes the coordinator; orchestration removes the ambiguity. You can have decoupled services and an explicit flow at the same time.
What must be true either way
Every step idempotent, because the orchestrator will retry and retries are the normal case. State persisted before each command, so a coordinator crash can resume knowing exactly which step was in flight. And semantic locks so other processes do not treat a provisional state as final.