What are the trade-offs between choreography and orchestration in complex microservices workflows?

In choreography, each service reacts to events and publishes new events — there is no central coordinator. Services are maximally decoupled: adding a new step means adding a new subscriber without touching existing services. However, the overall business process is implicit and scattered across many services, making it very hard to visualize, debug, and monitor. In orchestration, a central saga orchestrator explicitly commands each participant in sequence and handles compensating rollbacks centrally. The business process is explicit and visible in one place, making it easy to trace, debug, and modify. The orchestrator becomes a coupling point (changes to the workflow require changing the orchestrator) and a potential bottleneck. For simple workflows with few participants, choreography is clean and scalable. For complex, long-running business processes with many failure modes (like order fulfillment), orchestration's visibility and centralized error handling justify the coupling cost. Many mature systems use both: choreography between bounded contexts, orchestration within a bounded context.