Choreography vs Orchestration

Choreography and orchestration are two patterns for coordinating work across microservices. Choreography lets services react to events independently. Orchestration uses a central coordinator to direct the workflow.

Choreography

In choreography, there is no central controller. Each service knows what events to listen for and what to do in response. When an order is placed, the payment service reacts to the OrderPlaced event, the inventory service reacts to PaymentCompleted, and so on.

This is like a dance where each dancer knows their moves — no conductor needed. The advantage is loose coupling: adding a new step (e.g., fraud detection) means adding a new subscriber without changing existing services.

Orchestration

In orchestration, a central coordinator (the orchestrator) directs the workflow explicitly. It calls the payment service, waits for the result, then calls the inventory service, handles errors, and manages compensating transactions.

This is like a conductor leading an orchestra. Tools like Temporal and AWS Step Functions make orchestration practical.

The Event Spaghetti Problem

Choreography works well for simple flows (2-4 steps). But as workflows grow, the implicit dependencies between events become impossible to reason about. You end up with "event spaghetti" — dozens of services reacting to dozens of events with no clear picture of the overall flow.

The Hybrid Approach

Most mature systems use both: choreography for loosely coupled domain events (notifications, analytics) and orchestration for critical business workflows (order processing, payment flows).

For more patterns, see our saga pattern concept and system design interview guide. Explore pricing for full access.

The Bottom Line

Use choreography for simple, loosely coupled event reactions. Use orchestration for complex, multi-step business processes where visibility, error handling, and debuggability matter.