Choreography
Choreography distributes process decisions among reacting participants.
- EventDescribes a past business fact.
- CorrelationConnects reactions into a process instance.
- Overall statusShows completion, stalls, and manual resolution.
Context
Why this is important
Autonomy requires separate evidence for the complete end-to-end path.
The distributed saga is a hypothetical variant; currently seven modules run together with one database.
Who reacts to which event?
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 event reactions and central commands. A shipping rejection triggers compensations only through explicitly designed reactions: cancel the order, cancel the authorization, and release stock.
This is how you read the picture
- Event Named fact between the publishing and reacting module
- Correlation Shared sequence for order B-1042
- Overall status Status display for progress, completion and required clarification
Hypothetical variant Distributed saga for order B-1042
Flow in progressB-1042 · status of this simplified learning flow
Participants react to past events.
OrderCreatedStep 1 of 4
OrderCreated
Order B-1042 for two mugs has been created.
Decision ownerOrder publishes the fact; Inventory owns its reaction. Order owns the order record and the decision to start the flow.
Benefits & limitations
Helps if:
- Participants react autonom to stable events.
- New reactions should be added without changing central flow logic.
- Overall progress can be derived reliably from events.
Boundaries
- Long chains and feedback loops make behavior hard to predict.
- A missing event can halt the overall process invisibly.
- Schema changes have a distributed change radius across subscribers.
In practice
- Draw the event chain from ReturnReceived to RefundCompleted. Assign each event a producing and reacting shop module. Record a correlation identifier so the full process can be reconstructed from independently emitted events.
- Drop or duplicate an intermediate event. Check correlation, idempotency, and whether a stalled overall process can be detected.
- Compare distributed reactions with an explicit orchestrator when a refund step is added. Assess visibility and change radius.
Read the detailed explanation
Each participant reacts to a past event, performs a local decision, and publishes its result. Correlation and causation connect individual reactions into one process instance.
Autonomy reduces central control but makes it harder to tell where a flow is stuck or complete. A status aggregate, distributed traces, and defined completion events make overall progress testable.
Saga covers compensation. Publish-Subscribe provides distribution but alone does not guarantee a complete business flow.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How can you identify distributed ownership of the flow?
View the solution with justification
Each module publishes a past fact; the next module owns its designed reaction to that fact.
ApplyingTransferred to a new situation
How does compensation happen after shipping rejects the job?
View the solution with justification
Order, Payment, and Inventory need explicit reactions for cancellation and release, plus idempotency for each event identifier.
EvaluateWeighing an alternative
When does the distributed reaction chain become difficult to manage?
View the solution with justification
When failure paths, completion, and change impact can only be reconstructed across many participants.
Explore further
These building blocks continue the thoughts of this page.