A multi-step business process spans several services. When should it be orchestrated by a coordinator and when choreographed through events, and how do you tell which one you already have?

The distinction

Orchestration: a coordinator holds the process definition and calls each service in turn. The process exists in one place and can be read.

Choreography: each service reacts to events and emits its own. No component knows the whole process — it is an emergent property of the reactions.

When orchestration is right

• The process has business meaning and will change. Order fulfilment, onboarding, claims handling, KYC. Someone will ask "where is order 12345 and why is it stuck", and the answer must be available — which requires that the process exists somewhere as an entity.
• Compensation is required. Rolling back a partially-completed process needs someone to know what has happened so far and in what order.
• The process is long-running — hours to months — with waits, timeouts and retries.
• Steps are conditional, with branches based on business rules.
• Visibility matters, for operations, for customer service, or for a regulator.

Durable-execution engines make orchestration substantially more attractive than it was, because the historical objection — that the coordinator becomes a stateful component with its own failure and versioning problems — is what those engines exist to solve.

When choreography is right

• Reactions are genuinely independent. Order placed → send a confirmation email, update analytics, award loyalty points, notify the warehouse. None of these needs to know about the others, and adding a fifth reaction should not require changing anything that exists.
• The producer should not know its consumers, which is the strongest argument for the style.
• No compensation across steps, because there is no overall transaction to unwind.
• Loose coupling is worth more than visibility, which is true for notifications, analytics and side effects and false for anything transactional.

How to tell which you already have

A useful diagnostic: can you point at the code that defines the process?

If yes, it is orchestrated. If the process only exists as a chain of subscriptions across seven repositories, it is choreographed — and if that process has business meaning and compensation requirements, that is the problem, whether or not anybody has named it.

The characteristic failure of choreography is a process nobody can see. Debugging requires reconstructing the flow from logs across services; a stuck instance is invisible until a customer complains; adding a step means finding every subscriber; and nobody can answer "what happens when a customer places an order" without reading seven codebases.

The pattern that usually fits

Orchestrate the transactional core; choreograph the periphery.

The order process — payment, reservation, fulfilment, with compensation — is orchestrated, because it needs visibility, ordering and rollback. The reactions to "order completed" — email, analytics, loyalty, recommendations — are choreographed, because they are independent and the core should not know about them.

This is not a compromise. It matches the mechanism to the property each part actually needs, which is that one part has an invariant to maintain and the other does not.