An order flows through payment, restaurant acceptance, courier assignment and delivery. Should the coordination be orchestrated or choreographed?

What each gives

Choreography: each service reacts to events published by others. No central coordinator, low coupling in the sense that services do not call each other, and easy to add a new reactor.

Orchestration: a coordinator holds the process state and invokes each step. The sequence is explicit in one place, the current state is queryable, and failure handling is centralised.

Which fits this flow

Orchestration, for reasons that are operational rather than architectural:

• Someone will ask "where is my order?", and with choreography there is no single place that knows. Reconstructing state from an event log during a customer conversation is not a viable support model.
• The sequence has ordering constraints and compensations — a courier assigned before restaurant acceptance is a wasted trip, and a failed payment after courier dispatch is a real cost. Those relationships are the process, and encoding them implicitly across five services makes them unknowable.
• The process involves external parties whose failures need explicit handling with timeouts and compensation.
• The flow changes as the business changes, and changing a sequence expressed across five reactors means changing five services in a coordinated release.

Where choreography is genuinely better

For reactions rather than for processes. An analytics consumer, a notification sender, a fraud scorer, a loyalty-points accumulator — all of these react to "order placed" and none of them is part of the order's sequence. Adding a new one should require no change to anything, which is exactly what choreography delivers.

The hybrid that is usually correct

Orchestrate the process, choreograph the reactions. The order lifecycle is a workflow with an explicit coordinator; everything downstream that merely observes it subscribes to events.

The objection to answer

"The orchestrator is a single point of failure and a god object." It is a single point of failure only if it is not durable — a workflow engine with persisted state resumes rather than losing progress. And it is a god object only if it contains business logic belonging to the services; an orchestrator that sequences and handles failure, while the services own their own decisions, is a coordinator rather than a monolith.