Architecture Patterns ARCH · 09 · 01

Choreography vs orchestration

Choreography lets services react to events with no central coordinator — the flow is implicit. Orchestration uses a central process-manager that explicitly directs each step. The real tradeoff is coupling vs visibility.

ARCH Senior ◷ 25 min

Level

FoundationsJuniorMiddleSenior

A team at a B2B billing platform started with four services communicating via events — choreography. Each service subscribed to events from other services and emitted its own. The overall order flow existed as emergent behavior across the subscriptions. Eighteen months later they had twelve services. When a new requirement arrived — “pause the order process if the customer exceeds their credit limit” — nobody knew which service to change. They spent three days tracing logs to map the implicit flow across twelve event subscriptions. Then they considered switching to an orchestrated saga pattern, which would make the flow explicit in one place. But that meant a central orchestrator that all twelve services would depend on. They had traded one problem for another.

Choreography: implicit flow from event subscriptions

In a choreographed system, each service knows only its own role: “when I see event X, I do Y and emit Z.” There is no central authority. The overall process flow is not declared anywhere — it emerges from the combination of subscriptions across all services.

The B2B billing example with four services:

OrderService receives a customer request and emits OrderPlaced
PaymentService subscribes to OrderPlaced, charges the customer, emits PaymentProcessed
InventoryService subscribes to PaymentProcessed, reserves stock, emits InventoryReserved
ShippingService subscribes to InventoryReserved, schedules delivery, emits ShipmentScheduled

No service knows the full picture. PaymentService does not know that ShippingService exists. The flow is loosely coupled: adding a fifth service that reacts to PaymentProcessed requires zero changes to PaymentService. But the flow is invisible: the only way to understand the complete order lifecycle is to read every service’s subscription and event catalog.

Each service subscribes to events from the previous step and emits its own. The overall order flow is implicit — it exists only as the aggregate behavior of four independent subscriptions. No service is aware of the full flow.

Orchestration: explicit flow in one place

In an orchestrated system, a central process-manager — the orchestrator — holds the complete business flow and directs each participant step by step. The orchestrator knows: “first charge the customer, then reserve inventory, then schedule shipment.” Participants are called by the orchestrator; they do not subscribe to each other’s events.

The B2B billing example with an OrderSaga orchestrator:

OrderSaga receives an order creation command
It calls PaymentService: “charge customer X for order Y”
On success, it calls InventoryService: “reserve stock for order Y”
On success, it calls ShippingService: “schedule delivery for order Y”
If any step fails, OrderSaga knows exactly what has been done and can coordinate compensation

The flow is now explicit and visible in one place. When the requirement “pause if credit limit exceeded” arrives, there is one service to change: OrderSaga. The tradeoff is that all participants now depend on the orchestrator — it has become a coupling hub.

The OrderSaga orchestrator holds the complete flow and directs participants explicitly. No service subscribes to another. The flow is visible and modifiable in one place, but all participants depend on the orchestrator.

Quiz

The B2B billing platform's team traced their 12-service choreographed system for three days trying to find where to implement 'pause if credit limit exceeded.' A developer proposes switching to full orchestration. A senior engineer objects: 'We should not switch the entire system — there is a structural reason choreography became hard to trace, but that reason is specific to this flow.' What structural property of choreography caused the traceability problem, and what is the senior engineer implying?

The real tradeoff: coupling vs visibility

The binary framing — “choreography is decoupled, orchestration is coupled” — obscures the real tradeoff. Both patterns involve coupling; they just couple different things differently.

Choreography coupling: each service is coupled to the event schema. PaymentService is coupled to the shape of OrderPlaced. If OrderPlaced gains a required field, PaymentService must be updated. Services are decoupled from each other’s existence but coupled to the event contract.

Orchestration coupling: each service is coupled to the orchestrator’s expectations. PaymentService must respond to the orchestrator’s ChargeCustomer command in a way the orchestrator understands. The orchestrator is coupled to all participants.

The visibility/control dimension is where orchestration wins clearly: the flow is auditable, testable, and modifiable in one place. Business rules (“pause if credit limit exceeded”, “retry payment twice before failing”) live in the orchestrator, not scattered across subscriber logic. This matters most in flows with frequent requirement changes or complex multi-step coordination.

Both patterns couple — choreography to the event schema, orchestration to the coordinator. The real tradeoff is visibility: orchestration makes the flow auditable and changeable in one place, choreography keeps it implicit but invisible.

▸lesson.inset.note

Neither pattern is a default. Choreography suits stable, simple flows between few services where the decoupling benefit outweighs the visibility cost. Orchestration suits complex, frequently-changing flows where business rules must be legible, auditable, and modifiable without touching participant services. Many real systems use both: choreography for independent domain events (a notification service reacting to any order event), orchestration for complex coordinated transactions (the order fulfillment saga).

Quiz

A team is building a new notification system that sends emails when various events occur across their platform: order placed, payment received, shipment scheduled, support ticket opened. They are choosing between choreography and orchestration for the notification flow. Which pattern fits better and why?

When each pattern breaks down

Choreography breaks down when:

The flow spans many services and business rules require cross-service coordination logic
Requirements change frequently and the right service to modify is not obvious
Debugging a failed transaction requires tracing events across many services with no single point of truth
A new “global” business rule must affect the flow but has no natural owner in the choreographed topology

Orchestration breaks down when:

The orchestrator accumulates business logic beyond coordination (it becomes a god-object)
All flow changes require touching the orchestrator, making it a deployment bottleneck
The orchestrator becomes a single point of failure for all coordinated transactions
The coordinator is technically correct but the business team owns participant services independently and the coupling to a shared orchestrator creates organizational friction

The B2B billing platform’s 12-service problem was a choreography-breaking-down scenario: too many services, too many cross-cutting business rules, emergent flow too hard to trace. But switching blindly to a monolithic OrderSaga that orchestrates all 12 services would create a fragile coupling hub. The right design would likely identify which flows need orchestration (the critical order fulfillment path) and which can stay choreographed (ancillary reactions like audit logging, notifications, metrics).

Quiz

A team's OrderSaga orchestrator has grown to 800 lines. It now contains: routing logic (call PaymentService), business rules ('if customer tier is gold, skip credit check'), retry policies ('retry payment up to 3 times'), and formatting logic ('format the order summary for the shipping label'). A senior engineer says the orchestrator has failed. What failure mode is this, and what is the structural fix?

Recall before you leave

01
What makes choreography hard to debug when a transaction fails mid-flow?
02
What is the key coupling difference between choreography and orchestration?
03
Name two signs that a choreographed flow should be migrated to orchestration.

Recap

The B2B billing team’s three-day log-tracing session was a choreography failure. With twelve services, the implicit flow — which exists only as the aggregate behavior of twelve event subscriptions — had grown beyond the team’s ability to reason about it. When a new cross-cutting rule arrived, there was no obvious place to put it.

Choreography’s strength is decoupling: services react to events without knowing each other exists. That strength becomes a liability when the flow is complex, when business rules must span multiple participants, or when the “where should this change go?” question takes days to answer.

Orchestration makes the flow explicit in one place. The OrderSaga knows the complete sequence, owns the business rules, and is the single place to add “pause if credit limit exceeded.” The cost is that all participants depend on the orchestrator — it is a coupling hub. And if the orchestrator accumulates business logic beyond coordination, it becomes a god-object.

The practical pattern: use choreography for simple, stable reactions (notifications, audit logging, metrics) and orchestration for complex, frequently-changing transactions where the flow must be legible, auditable, and modifiable. Many systems use both simultaneously.

Practice

Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.

recallapplystretch0 of 4 done

Something unclear?

Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.