⌘ The Architecture Reference

Ms communication · Microservices · Intermediate

Choreography vs Orchestration

Two ways to coordinate a multi-service business process: a central orchestrator that commands the flow, or choreographed services reacting to broadcast events — and when to choose each.

Ms communication Intermediate ⏱ 4 min read Complete

🧭 Analogy

An orchestra has a conductor who cues each section in turn — clear, visible, and centrally controlled. A troupe of dancers performs without a conductor: each dancer reacts to the music and to the others, producing a coordinated whole with no one in charge. Orchestration has a conductor; choreography is the dancers.

Coordinating a process across services

Once a business process — say, creating a customer order — spans several services, something has to coordinate the steps. There are two styles, and the difference is who knows about the flow.

graph TD
subgraph Orchestration
  O["Order Processor<br/>(orchestrator)"]
  O -->|"command"| W1["Warehouse"]
  O -->|"command"| P1["Payment"]
  O -->|"command"| L1["Loyalty"]
end
subgraph Choreography
  OE["Order Placed<br/>event on broker"]
  OE --> W2["Warehouse reacts"]
  OE --> P2["Payment reacts"]
  OE --> L2["Loyalty reacts"]
end

Orchestration — command and control

A central orchestrator (e.g., Order Processor) defines the order of steps and triggers each one, typically via request-response.

  • Pros: explicit and understandable — the whole process lives in one readable place; easy to see and reason about its state.
  • Cons: higher domain coupling (the orchestrator must know about every collaborator) and a tendency to make downstream services anemic — “if logic has a place where it can be centralized, it will become centralized.”
  • Mitigation: use different services as orchestrators for different flows, so no single god-service accretes all the logic. Newman dislikes heavyweight BPM tools; prefer code, with developer-friendly options like Camunda/Zeebe if needed.

Choreography — react to events

Services react to events broadcast on a message broker; no service knows about another.

  • Pros: drastically lower coupling; responsibility is distributed; easy to add a new reactor without touching the publishers.
  • Cons: harder to see the overall process and to know what state a saga is in.
  • Solution: propagate a correlation ID through every event, plus a dedicated service that consumes events to project saga state, restoring observability.
graph LR
E1["Order Placed<br/>(corr-id: 9f2)"] --> Mon["Saga-state projector"]
E2["Payment Taken<br/>(corr-id: 9f2)"] --> Mon
E3["Stock Reserved<br/>(corr-id: 9f2)"] --> Mon
Mon --> View["Order 9f2:<br/>placed -> paid -> reserved"]

💡 You can mix and nest

The styles aren’t exclusive. You can run an orchestrated flow inside the Warehouse boundary that participates in a larger choreographed saga; nested sagas exist for complex processes. Match the style to the ownership and complexity of each segment.

⚠️ Centralization creeps

The pull toward orchestration isn’t only a design choice — it’s gravitational. Logic naturally drifts to wherever it can be centralized, hollowing out collaborators into dumb CRUD wrappers. If you orchestrate, deliberately keep real domain logic in the services and resist the urge to thicken the orchestrator.

The rule of thumb

🔑 Key insight

Be relaxed about orchestration when one team owns the whole process — central control is manageable and the visibility is worth it. Prefer choreography across multiple teams, where looser coupling lets each team evolve independently. This is Conway’s law applied to workflow design.

This choice is the engine room of sagas — the pattern that coordinates a sequence of state changes across services without distributed transactions, in either an orchestrated or choreographed style.

See also

When to use it — and when not

✅ Reach for it when

  • You are implementing a business process that spans several services.
  • You need to decide between centralized control and distributed reaction.
  • You want to reason about coupling versus visibility of a workflow.

⛔ Think twice when

  • The process lives entirely within one service.
  • You only need point-to-point request-response — see communication styles.
ms-communicationCommunication Styles: Sync vs Async

Choose the communication style before the technology — request-response vs event-driven, synchronous vs asynchronous — and understand temporal coupling, cascading failures, and what goes in an event.

ms-communicationSagas: Distributed Workflows Without Distributed Transactions

Coordinate multiple state changes across services without long-held locks by modeling a process as a sequence of local transactions, with compensating actions for rollback.

ms-organizationConway's Law and Team Topologies

Systems mirror the communication structure of the organizations that build them — so align teams to business domains, use the four Team Topologies team types, and apply the Inverse Conway Maneuver incrementally.

Check your understanding

Score: 0 / 4

1. What characterizes an orchestrated process?

Orchestration uses command-and-control from one service — explicit and easy to follow, but with higher domain coupling.

2. What is the main downside of orchestration?

The orchestrator knows about all the services; 'if logic has a place where it can be centralized, it will become centralized,' leaving collaborators anemic.

3. What does choreography need to make saga state observable?

Because no single service sees the whole flow, a correlation ID and a consumer that builds a view of saga state restore visibility.

4. What is Newman's team-based rule of thumb?

Single-team ownership makes centralized orchestration manageable; spanning teams favors the looser coupling of choreography.

Comments

Sign in with GitHub to join the discussion.