Choreography

A coordination pattern where services react to events independently, without a central orchestrator.

In choreography, there is no central coordinator. Each service listens for events, does its work, and publishes new events for others to react to. The workflow emerges from the chain of reactions, not from a single place that knows all the steps.

Consider a ticket booking system. When a user places an order, the Orders service publishes OrderPlaced. The Payments service picks it up, charges the customer, and publishes PaymentReceived. The Shipping service reacts to that and schedules delivery. No single component orchestrates the full flow.

This is the opposite of orchestration, where a process manager or saga sits in the middle and tells each service what to do next.

Choreography works well when the process is simple: a few steps, no branching logic, no need to track partial progress. You don't need a central component managing state. Each service is autonomous and only cares about the events it subscribes to.

The tradeoff is visibility. When something goes wrong, there is no single place to check the status of the entire process. The flow is spread across multiple services, and debugging requires piecing together events from different sources. Proper tracing helps, but it doesn't fully replace the clarity of having one component that knows the whole picture.

Choreography also makes compensation harder. If a later step fails and you need to undo earlier steps, each service must handle its own rollback logic. With an orchestrator, one component coordinates the compensating actions in the right order.

Start with choreography when the process is straightforward. When it grows in complexity, with more steps, conditional paths, or compensation requirements, consider moving to orchestration with a saga or process manager.