Coordination · Established
Event Choreography
Also known as: Choreography, Event-driven coordination
Event choreography coordinates services without a central controller: each service reacts to events it subscribes to and publishes new events, and the overall workflow emerges from these reactions.
01Problem it solves
A central orchestrator couples every service to one component and one team. As domains grow, that coordinator becomes a bottleneck for change, scale and ownership.
02Use when / Avoid when
Use when
- Services are owned by independent teams that should deploy without coordination.
- Many consumers react to the same business fact (order placed, user signed up).
- The flow is short or loosely ordered and each step is a natural reaction to the previous event.
Avoid when
- You need a single place to see, change and reason about the end-to-end flow.
- Strict ordering, deadlines or complex compensation across many steps are required; orchestrate instead.
- Your team lacks event tracing and schema governance.
03How it works
- 1PublishA service commits a state change and emits a domain event.
- 2DeliverAn event broker delivers it to every subscriber.
- 3ReactEach subscriber performs its local work independently.
- 4EmitSubscribers publish follow-up events, continuing the flow.
04Capabilities
| Capability | What it means |
|---|---|
| Decoupled coordination | Participants coordinate by publishing and reacting to events, with no single component owning the end-to-end flow. |
| Parallel execution | Independent units of work run concurrently instead of one after another. |
05Tradeoffs
| Aspect | You gain | You pay |
|---|---|---|
| Coupling | Services depend on event contracts, not on each other. | The end-to-end flow is implicit and spread across services. |
| Scalability | New consumers attach without changing producers. | Debugging requires distributed tracing and event lineage. |
06Failure considerations
| Failure mode | Mitigation |
|---|---|
| Cyclic event chains cause infinite loops. | Carry correlation and causation ids and detect repeated cycles. |
| The state change commits but the event is never published (dual write). | Use the transactional outbox pattern or change data capture. |
| Consumers process duplicate or out-of-order events. | Make handlers idempotent and use per-key ordering where required. |
07Implementations
Examples of products and frameworks that implement this pattern. Listed as evidence, not endorsement.
| Implementation | Mechanism |
|---|---|
| Apache KafkaEvent streaming / event bus | Services publish domain events to topics; independent consumer groups react to them. |
| Amazon EventBridgeEvent streaming / event bus | Services put events on a bus; rules route matching events to independent targets. |