Orchestration vs Choreography in Microservices: What is the Difference?
Compare orchestration and choreography for coordinating microservices workflows, with Saga examples and trade-offs.
Expected Interview Answer
Orchestration coordinates a multi-service workflow through a central controller that explicitly tells each service what to do and in what order, while choreography has no central controller — each service reacts to events published by others and decides its own next action, so the overall workflow emerges from many independent, decentralized reactions.
In orchestration, a workflow engine or dedicated orchestrator service (like a Saga orchestrator, Temporal, or AWS Step Functions) owns the sequence: it calls service A, waits for the result, calls service B, and if service B fails, it explicitly issues compensating actions to undo A. This makes the overall flow easy to see in one place, easy to test, and easy to modify, but the orchestrator becomes a central dependency and a potential bottleneck or single point of coordination logic. In choreography, service A simply publishes an event like OrderPlaced, and services B, C, and D independently subscribe and react — no service knows about or controls the others. This scales well and keeps services fully decoupled, but the overall business process is implicit, scattered across many services’ event handlers, which makes it much harder to trace, test end-to-end, or reason about failure and compensation as workflows grow complex. Most real systems mix both: choreography for simple, loosely coupled reactions and orchestration for complex, multi-step business transactions that need explicit compensation logic.
- Orchestration gives a single, explicit, easy-to-trace definition of the workflow
- Orchestration centralizes compensation/rollback logic when a step fails
- Choreography keeps services fully decoupled with no shared coordination dependency
- Choreography scales naturally as new reactive services can subscribe without changing existing ones
AI Mentor Explanation
Orchestration is like a captain calling every field placement and bowling change from the middle, explicitly directing each player where to stand and when to bowl, so the whole game plan lives in one person’s head and can be adjusted instantly. Choreography is like a well-drilled fielding unit where each player simply reacts to the ball’s trajectory and their teammates’ movements without waiting for instructions, adjusting position independently based on what they observe. The captain’s plan is easy to explain to a commentator in one sentence; the fielders’ instinctive reactions are efficient but hard to fully script or predict in advance. Both approaches coordinate the same team, just through very different control structures.
Step-by-Step Explanation
Step 1
Choose the coordination model
Decide whether the workflow needs an explicit central controller (orchestration) or fully decoupled reactive services (choreography).
Step 2
Orchestration: central controller drives steps
A workflow engine or Saga orchestrator calls each service in sequence and owns the overall state and compensation logic.
Step 3
Choreography: services react to events
Each service publishes domain events; interested services subscribe and independently decide their own next action.
Step 4
Handle failure and compensation
Orchestration issues explicit compensating calls on failure; choreography relies on each service publishing its own compensating event.
What Interviewer Expects
- Clearly contrasts central control (orchestration) with decentralized reaction (choreography)
- Names concrete tools/examples: Saga orchestrator, Temporal, Step Functions vs event-driven pub/sub
- Discusses traceability and testability trade-offs, not just “which is better”
- Recognizes that real systems often mix both rather than picking one exclusively
Common Mistakes
- Claiming one approach is universally better without discussing the workflow’s complexity
- Not mentioning compensation/rollback handling for failed steps in either model
- Confusing choreography with simple synchronous service-to-service calls
- Ignoring the debuggability and observability cost of scattered choreography logic
Best Answer (HR Friendly)
“Orchestration means one central process explicitly tells each service what to do and in what order, like a conductor leading an orchestra. Choreography means there is no central conductor — each service just reacts to events from other services and decides its own next step. Orchestration is easier to follow and debug for complex workflows, while choreography keeps services more independent and scales better for simpler reactive flows.”
Code Example
// Orchestration: a central Saga orchestrator owns the sequence
async function fulfillOrderOrchestrated(order) {
const payment = await paymentService.charge(order)
if (!payment.success) return fail("payment declined")
const reserved = await inventoryService.reserve(order)
if (!reserved.success) {
await paymentService.refund(payment.id) // explicit compensation
return fail("inventory unavailable")
}
await shippingService.schedule(order)
return succeed(order)
}
// Choreography: each service reacts to events independently
// order-service.js
eventBus.publish("OrderPlaced", { orderId })
// payment-service.js
eventBus.subscribe("OrderPlaced", async (evt) => {
const result = await charge(evt.orderId)
eventBus.publish(result.success ? "PaymentCharged" : "PaymentFailed", evt)
})
// inventory-service.js
eventBus.subscribe("PaymentCharged", async (evt) => {
const ok = await reserveStock(evt.orderId)
eventBus.publish(ok ? "InventoryReserved" : "InventoryFailed", evt)
})Follow-up Questions
- How would you implement the Saga pattern using orchestration versus choreography?
- What makes choreographed workflows harder to debug in production than orchestrated ones?
- When would you deliberately mix both models in the same system?
- How does an orchestrator itself avoid becoming a single point of failure?
MCQ Practice
1. What best describes the orchestration coordination model?
Orchestration relies on a central process (like a Saga orchestrator) that explicitly drives each step of the workflow.
2. What is the main downside of the choreography model as workflows grow complex?
Because logic is spread across many services’ event handlers, choreography becomes harder to observe and debug as complexity grows.
3. In practice, how do most real distributed systems use these two models?
Complex transactional workflows benefit from orchestration’s explicit compensation logic, while simpler reactive flows suit choreography.
Flash Cards
Orchestration in one line? — A central controller explicitly directs each service’s step in a workflow.
Choreography in one line? — Services react independently to published events with no central controller.
Orchestration trade-off? — Easy to trace and modify, but the orchestrator can become a coordination bottleneck.
Choreography trade-off? — Fully decoupled and scalable, but the overall process is implicit and hard to debug end-to-end.