A travel platform's booking process spans six systems and takes days to change. Where should the process logic live, and what is the trade-off?
Show the full answer Hide the answer
Why the process needs an owner
The symptom — days to change a process — means the sequence is encoded in six places. Each system knows what comes next, so changing the order requires coordinated changes across six teams, and no single component can answer "where is this booking and why is it stuck".
Choreography fails here for a specific reason: no component knows the state of the process. Diagnosing a stuck booking means reconstructing it from six event logs; timeouts have no owner; and concurrent cancellation races progression with no arbiter.
What the orchestrator provides
- An authoritative current state, so "why is this stuck" is answerable.
- A natural home for timeouts, each with a defined action. A wait state with no timeout produces bookings stuck forever.
- A single place where the sequence is defined, so changing it is one change.
- Enforcement that only one transition applies at a time, resolving the concurrency races.
What the capabilities provide
Services that expose what they do and know nothing about when they are called: reserve inventory, authorise payment, issue confirmation. They are reusable across processes precisely because they carry no sequence.
The trade-off, stated honestly
The orchestrator is a central component every process flows through — a new operational dependency and a potential bottleneck for change if it accumulates logic that belongs in services. The failure mode is a distributed monolith: an orchestrator holding pricing rules, eligibility logic and business policy that every team must change and nobody owns.
Keep it to sequencing, timeouts and compensation. Not business rules.
The distinction that resolves most of this
Orchestrate obligations; choreograph notifications.
Steps that carry an obligation — reserve, charge, fulfil — need an owner, an acknowledgement and a timeout, so they belong in the orchestrator. Events that are merely notifications — "booking confirmed" consumed by analytics, search and marketing — should be published freely, with consumers added without touching the publisher.
Systems that get this wrong in one direction stall on a central bottleneck; in the other they lose the ability to answer where anything is.