Choreography vs Orchestration

Two ways to coordinate services

Once services talk via events, a multi-step business process can be coordinated two ways:

• Choreography — each service reacts to events and emits its own; there is no central brain. OrderPlaced → inventory reserves and emits InventoryReserved → payment charges and emits PaymentCaptured → shipping ships. Loosely coupled, scales organisationally, but the end-to-end flow is emergent — no single place shows 'what is the state of order 42?'.
• Orchestration — a central orchestrator (a saga/workflow service) issues commands and awaits replies, owning the process explicitly. Easy to reason about and to visualise; but it's a coupling point and can become a god-service.

Rule of thumb: choreography for autonomy between teams and simple flows; orchestration when the process itself is the product (loan approval, fulfilment) and you need visibility, timeouts and compensation in one place. Most mature systems mix both: choreographed between bounded contexts, orchestrated within one.

Choreography is a flock of starlings — no leader, stunning coordination from local rules, but ask 'why did the flock turn left?' and there's no one to ask. Orchestration is a symphony — the conductor owns the timeline, every entrance is intentional, but the conductor is a single point of everything.