Event Choreography¶
Coordination pattern — instantiates Message-Mediated State Coordination
Coordinates many participants with no central conductor — each publishes events about what it just did and reacts to others', so the workflow emerges from the exchange itself.
Event Choreography coordinates a set of autonomous participants without any central orchestrator. Each participant publishes events — factual announcements of what it just did, in the past tense — onto a shared bus, and subscribes to the events it cares about. There is no script that says "first payment, then inventory, then shipping"; that sequence is an emergent property of who reacts to what. The defining move, and what separates choreography from every sibling here, is that no single component owns the end-to-end flow — coordination is distributed into the subscribers' reaction rules, so a workflow exists only as the sum of independent parties each doing their own part when the right event arrives.
Example¶
An online retailer processes orders across four independent services. When a shopper checks out, the Order service does one thing: it publishes OrderPlaced. It does not call payment, inventory, or shipping — it doesn't know they exist. The Payment service, subscribed to OrderPlaced, captures the charge and publishes PaymentCaptured. Inventory, subscribed to that, reserves stock and publishes StockReserved. Shipping, subscribed to StockReserved, prints a label. Each service reacts only to the events it cares about and announces only its own outcome.
The payoff shows the day the retailer adds a loyalty-points service: it simply subscribes to PaymentCaptured and starts awarding points — no existing service is touched or redeployed. The workflow grew by one participant with zero central change. The cost shows up the same day someone asks "where is order #4471 right now?" — and discovers the answer lives nowhere, scattered across four services' logs, because the flow was never written down in one place.
How it works¶
The pattern rests on three commitments that distinguish it from a scripted, orchestrated flow:
- Events, not commands. Participants publish facts ("this happened"), never instructions ("do this"). A publisher never names its consumers, which is what keeps them decoupled.
- A shared bus does the routing. Publishers emit to a topic; the broker fans each event out to whoever subscribed. The publisher is oblivious to who — or how many — react.
- Reaction rules are the workflow. Each subscriber's "on event X, do Y and emit Z" rule is a small local decision; the global process is just these rules chaining. Nobody holds the whole chain.
Tuning parameters¶
- Choreography vs. orchestration balance — how much of the flow is emergent versus steered by a central coordinator. More choreography buys looser coupling and easier extension; it costs end-to-end visibility and makes the overall process harder to reason about.
- Event granularity — coarse domain events versus many fine-grained ones. Finer events let reactors respond to exactly what they need but multiply bus chatter and coupling to detail.
- Fat vs. thin events — how much state each event carries. Fat events spare subscribers a callback to fetch data but bloat the schema and risk shipping stale copies.
- Subscription topology — broad broadcast versus narrowly routed topics. Broader makes adding a reactor trivial and raises noise; narrower is tidy but ossifies the routing.
- Duplicate/reorder tolerance — whether subscribers must be built to tolerate repeated or out-of-order events (on a real bus, almost always yes).
When it helps, and when it misleads¶
Its strength is open extensibility and loose coupling: you can add, remove, or change a reactor without touching the emitters, because no one names anyone. That makes choreography excellent for cross-team, cross-service coordination where the participants evolve independently.
Its failure mode is the mirror image: because the end-to-end process is implicit, no artifact anywhere describes the whole flow, so debugging, auditing, and answering "what state is this transaction in?" become archaeology. Emergent event chains can also loop or cascade in ways no single author foresaw. The classic misuse is reaching for choreography where the job actually wants a linear, auditable transaction with a clear owner — that is orchestration's territory, and forcing it into choreography trades a legible process for invisible coupling.[n1] The discipline that keeps it honest is to insist on end-to-end tracing even though control is decentralized, so the flow that exists nowhere in code is at least reconstructable in observation.
How it implements the components¶
message_intent_taxonomy— establishes events (published, past-tense facts) as the coordinating message class, deliberately distinct from directed commands or queries.broker_or_router_boundary— the publish/subscribe bus that decouples each emitter from its reactors and fans events out by topic.receiver_handler_rule— each participant's subscribe-and-react rule; the union of these local rules is the distributed workflow.
It does NOT define the contracts events must conform to (that's Message Schema Registry), guarantee their delivery or absorb duplicates (Durable Queue with Acknowledgement, Retry with Idempotency Key), or handle a directed command (Command Message Handler) — choreography is fire-and-forget broadcast, not conversation.
Related¶
- Instantiates: Message-Mediated State Coordination — choreography is the decentralized-coordination pattern at the archetype's core.
- Consumes: Message Schema Registry governs the shape of the events it publishes; a durable channel such as Durable Queue with Acknowledgement actually delivers them.
- Sibling mechanisms: Command Message Handler · Message Schema Registry · Dead-Letter Queue · Actor Mailbox Loop · Backpressure Signal · Bounded Mailbox or Queue · Correlation Trace Header · Durable Queue with Acknowledgement · Request-Reply Correlation · Retry with Idempotency Key · Transactional Outbox/Inbox Relay
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: At runtime a broker fans out published events and each subscriber's local reaction rule state-dependently performs work and emits the next event without a central conductor.
Nearest alternative: Structure, Architecture & Configuration — The shared bus and decoupled participants form an architecture, but the mechanism's operative behavior is the executable event-reaction chain during operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Distributed-systems and service-architecture practice cohered choreography as autonomous participants publishing events and reacting without a central process orchestrator.
Related originating lineages:
- Systems Thinking & Cybernetics — Decentralized coordination and emergence supply the conceptual account of order arising from local response rules.
Review resolution: The current reviewers agree that computer_science is primary. For the reported differences (alternate_origin_disagreement), the evidence supports single_lineage, specialized, and systems_cybernetics; these choices preserve materially formative origins without conflating later domain reach.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Choreography without observability is a trap: the decentralization that makes it extensible also makes it opaque. It should almost always be paired with a correlation/trace facility (see Correlation Trace Header) so that the workflow which exists nowhere in code can still be followed across participants. Many real systems are hybrids — choreographed between bounded contexts, orchestrated within one — precisely to keep the loose coupling without losing the auditable core.
[n1] The choreography-versus-orchestration distinction is a standard one in distributed-systems and workflow design: orchestration centralizes control in a conductor that issues commands; choreography distributes it into participants that react to events. Neither is strictly better — the failure is applying one where the other's trade-offs are needed. ↩