When to reach for it
- Systems must be loosely coupled.
- Events arrive from multiple sources.
- Expandability is highly important.
Event-driven Choreography.
No conductor. Each component listens for the events it cares about.
Each component reacts to events it subscribes to and emits its own, with no central conductor — the overall workflow is an emergent consequence of local event-and-reaction rules rather than an explicit plan.
In practiceAn e-commerce platform's fulfilment, notification, and analytics services each subscribe to an `order.placed` event, updating their own state independently rather than being called by a central controller.
When it backfires
- The global flow must be strictly traceable.
- Eventual consistency is unacceptable.
- Debugging without distributed tracing would be too difficult.
The tradeoff
High decoupling is gained against more difficult global control.
What it actually does.
Services react to events with no central conductor.
Two ways this pattern will hurt you.
The implicit graph nobody can see
Behaviour is the union of every subscription across every service. New components silently change global flow; debugging requires reconstructing a graph that was never written down.
Fix · Generate the choreography graph from registered subscriptions at deploy time. Treat the graph artefact as a first-class review surface.
No one can answer 'did the whole flow finish?'
With no central conductor, there is no single place that knows the end-to-end transaction completed. A dropped reaction leaves the flow half-done and nothing notices until a downstream state is missing.
Fix · Thread a correlation ID through every event and run a process monitor (or a saga) that tracks each flow to its terminal event and alerts on the ones that never arrive.
Where Event-driven Choreography is native.
Microsoft Agent Frameworkevent-driven agentsNative
Keep going