Choreography

Choreography coordinates a multi-service workflow without a central controller. Each service reacts to events emitted by others and, in turn, emits its own events. The overall process emerges from these local reactions, like dancers who each know their steps rather than following a conductor. It is one of the two ways to coordinate sagas and distributed business processes.

How It Works

Services communicate through a message broker or event bus. When a service completes a step, it publishes an event describing what happened. Other services subscribe to events relevant to them, perform their part, and publish further events. No component holds the end-to-end process definition; the flow is the sum of these event-driven interactions.

Reliable event publishing (for example via a transactional outbox) and idempotent, at-least-once consumption are essential so the workflow remains correct despite retries and failures.

Good choreographed systems publish events that describe facts ("PaymentCompleted") rather than commands aimed at a specific service, which keeps producers ignorant of consumers and allows new subscribers to be added freely. Distributed tracing and a central event catalog become important compensating tools, since the only way to see the whole flow is to follow the trail of events across services.

When to Use It

Use choreography when you want loosely coupled, autonomous services and an event-driven architecture, when workflows are relatively simple or linear, and when avoiding a central coordinator that all services depend on is a priority. It scales well and lets teams evolve their services independently.

Avoid it for complex workflows with many steps, branches, and compensations, where the lack of a single place to see the process makes it hard to understand and debug.

It also fits organizations that want strong team autonomy, since each team can subscribe to events and add behavior without coordinating changes through a central workflow owner.

Trade-offs

Choreography maximizes decoupling and avoids a coordinator bottleneck, but the business process is implicit and spread across services, making it hard to visualize, monitor, and reason about. Cyclic event dependencies can creep in. Debugging a flow means tracing events across many services. For simple flows the looseness is a strength; for complex ones it becomes a liability, and orchestration is preferable. Because no component owns the end-to-end view, investing early in tracing, an event schema registry, and clear event ownership is what keeps a choreographed system understandable as it grows.

Related Patterns

Choreography is the alternative to Orchestration for coordinating workflows, including the Saga pattern. It relies on event-driven messaging and is often built with a Transactional Outbox for reliable publishing and Event Sourcing for the event history. The Transactional Outbox and Event Sourcing patterns supply the reliable event backbone it depends on.

Example

In an order saga, the order service publishes OrderCreated. The payment service consumes it, charges the card, and publishes PaymentCompleted. The inventory service consumes that, reserves stock, and publishes StockReserved. The shipping service then schedules delivery. No central process exists; each service simply reacts to the previous event and emits the next.