When a business process spans multiple services — like a checkout flow that involves payment, inventory reservation, fraud checking, and email confirmation — you need a strategy for coordinating those steps. There are two fundamental patterns.
1. Orchestration: The Conductor Model
Imagine a symphony orchestra. The musicians do not look at each other to know when to play — they watch the conductor, who controls the tempo, the sequence, and the dynamics of the entire performance.
In Orchestration, one central service (the orchestrator) explicitly controls the entire business process. It calls each participant in sequence (or in parallel), waits for responses, handles errors, and decides what to do next.
[Order Orchestrator]
│
├─► POST /payments/charge → waits for success
├─► POST /inventory/reserve → waits for success
├─► POST /notifications/email → fire and forget
└─► returns "Order Complete" to client
Pros: The entire business process is visible in one place. Error handling is centralized — if payment fails, the orchestrator knows immediately and can compensate. Easy to audit and debug.
Cons: The orchestrator becomes a single point of failure and a potential bottleneck. It also tends to accumulate business logic over time, becoming a distributed monolith in disguise — a "god service" that knows too much about every other service's internals.
2. Choreography: The Dance Model
Imagine professional dancers performing a rehearsed routine without a conductor. Each dancer knows their cues — when the music changes, or when another dancer completes a move, they execute their next step. The coordination emerges from the interactions, not from a central director.
In Choreography, there is no central controller. Each service listens for events and reacts by doing its work and publishing its own events.
[Order Service] publishes → OrderPlaced
[Payment Service] hears OrderPlaced → charges card → publishes PaymentProcessed
[Inventory Service] hears PaymentProcessed → reserves stock → publishes StockReserved
[Email Service] hears StockReserved → sends confirmation email
Pros: Services are maximally decoupled. Adding a new step (e.g., a loyalty points service) requires zero changes to existing services — just subscribe to the relevant event. No single point of failure.
Cons: The overall business process is implicit — it exists only as an emergent property of the event chain. There is no single place to look to understand the full flow. Debugging a stuck process requires piecing together logs from multiple services across time. This is sometimes called "debugging by murder mystery." Handling failures and compensating transactions (e.g., refunding a payment if inventory reservation fails) requires careful design of compensating events.
Choosing Between Them
Use Orchestration when the process has complex conditional logic, requires strict sequencing, or needs centralized error handling and auditability (e.g., financial transactions, regulatory workflows). Use Choreography when services should be maximally independent, the process is relatively linear, and you prioritize extensibility over visibility. Many production systems use a hybrid: an orchestrator manages the critical path, while non-critical side effects (emails, analytics, notifications) are handled via choreography.
Interviewers frequently ask: "How do you handle a failure halfway through a multi-step distributed transaction?" This is testing knowledge of the Saga pattern. In an orchestrated saga, the orchestrator calls compensating transactions in reverse order (e.g., if inventory reservation fails after payment succeeded, the orchestrator calls the payment service to issue a refund). In a choreographed saga, each service publishes a failure event and other services listen for it to trigger their own compensating actions. The key insight to communicate: distributed systems cannot use database ACID transactions across service boundaries, so sagas are the standard alternative.