Orchestration
Orchestration makes flow knowledge and progress explicit.
- Process stateStores confirmed progress and open work.
- CommandRequests one participant to perform a local action.
- Resolution stateKeeps unknown or non-compensatable outcomes visible.
Context
Why this is important
Its value lies in visible control through failures and restarts.
The distributed saga is a hypothetical variant; currently seven modules run together with one database.
Who controls the next step?
The current shop processes B-1042 as a modular monolith with seven modules and a shared database: reserve stock, authorize payment, confirm the order, commission shipping. The visual compares a hypothetical distributed saga using central commands and event reactions. A shipping rejection leads to explicitly designed business operations: cancel the order, cancel the authorization, and release stock.
This is how you read the picture
- Process state The orchestrator owns the sequence and next transition
- Command Arrow from the orchestrator to the responsible business module
- Resolution state Failure path with cancellation, stock release and an unknown payment outcome
Hypothetical variant Distributed saga for order B-1042
Flow in progressB-1042 · status of this simplified learning flow
One coordinator owns the sequence and process state.
Step 1 of 4
Reserve stock
Order B-1042 for two mugs has been created.
Decision ownerThe orchestrator determines the next transition. Order owns the order record and the decision to start the flow.
Benefits & limitations
Helps if:
- Flow order and overall status must be centrally visible.
- Many failure paths or compensations need explicit control.
- One team owns flow evolution across participants.
Boundaries
- The orchestrator can become a tightly coupled business monolith if it absorbs participant rules.
- Its state and availability become part of every coordinated flow.
- Central visibility does not replace an atomic transaction across participants.
In practice
- Model return, warehouse receipt, refund approval, and payout as durable states. Show which step runs after a restart. Persist the transition before invoking the next participant, then verify that restart resumes safely.
- Simulate a timeout after a possible refund commit. Keep the outcome unresolved until a status query or idempotent retry clarifies it.
- Check whether centralized flow visibility justifies the added runtime dependency. Define high availability and migration of orchestrator state.
Read the detailed explanation
The orchestrator sends a command, waits for a correlated result, and durably stores the transition. After restart it continues at the open step instead of reconstructing the flow from volatile memory.
Timeout, unknown outcome, and business rejection are different states. Compensation is a new business action and can itself fail; manual resolution remains an explicit terminal state.
Saga covers local transactions and compensations. Partial Failures explains unknown outcomes across process boundaries.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How can you identify central ownership of the flow?
View the solution with justification
Every transition starts at the orchestrator; the business modules still decide on their local action.
ApplyingTransferred to a new situation
What work is required after shipping rejects the job?
View the solution with justification
The orchestrator initiates order cancellation, payment cancellation, and stock release as separate, idempotent business operations.
EvaluateWeighing an alternative
When does the orchestrator take on too much?
View the solution with justification
When it decides business-module eligibility and data instead of sequence, correlation, and process state.
Explore further
These building blocks continue the thoughts of this page.