# Orchestration versus choreography when the workflow breaks > Choose workflow control by traceability, recovery ownership, temporal coupling, and business visibility. Canonical URL: https://www.devobs.io/articles/orchestration-versus-choreography-debuggability/ By: Amara Okafor Published: 2026-04-24T03:25:14.482Z Updated: 2026-09-05 Section: Comparisons Choose orchestration when the business needs one explicit owner for progress, timeouts, compensation, and operator visibility. Choose choreography when events are durable facts with genuinely independent consumers and no component needs to know the whole process. Service count is a weak decision rule; the decisive question is who can explain and recover a failed workflow. ## Compare one order workflow An order requires payment authorization, inventory reservation, shipment creation, and customer notification. In choreography, the order service emits `OrderPlaced`; payment reacts and emits `PaymentAuthorized`; inventory reacts and emits `InventoryReserved`; shipment follows. Each service knows its input events and output facts. Adding a fraud subscriber does not require a central definition. The [AWS saga choreography guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-choreography.html) describes participants publishing events and other participants reacting, with local transactions and compensating actions. It also identifies challenges as participant count grows, including cyclic dependencies and difficulty tracking saga status. The issue is not events themselves; it is an implicit business process distributed across subscriptions. In orchestration, a workflow component records the order state, commands payment, waits for a result, commands inventory, applies timeouts, and starts compensation when needed. [AWS saga orchestration guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-orchestration.html) describes a central orchestrator coordinating participants and their compensating transactions. This makes the path visible but concentrates workflow logic and availability requirements in the orchestrator. ## Decide who owns change and recovery Ask who approves changing step order. If introducing fraud review between payment and inventory requires coordinated updates across four event consumers, the choreography has a hidden owner. An orchestrated definition may make the same change clearer and versionable. Conversely, if analytics and email independently consume `OrderPlaced` without affecting order completion, they should remain choreographed observers rather than steps in the critical workflow. For every transition, define timeout, retry policy, idempotency key, compensation, and terminal failure. Compensation is a new business action, not a database rollback: releasing inventory may fail and refunding payment may require review. The workflow must record attempts and unresolved compensation so operators can intervene safely. Temporal coupling exists in both styles. A synchronous orchestrator can require participants to be available immediately. A durable orchestrator can wait. Choreographed consumers can process later, but event retention, schema compatibility, and ordering still bound that freedom. Compare implementations, not labels. ## Make either style debuggable Give each workflow a stable ID carried through commands, events, logs, and traces. Record causation and correlation separately: one event may cause several new events within the same workflow. Persist participant state transitions before acknowledging input. Consumers must be idempotent because delivery can repeat. Provide an operator view showing current state, last transition, pending deadline, attempts, compensation state, and safe actions. In choreography this may require a dedicated process projection built from events. That projection is worthwhile when the business asks “Where is this order?”; its need may also reveal that critical control deserves an orchestrator. Never rely on a distributed trace as the only durable business record because sampling and retention differ from workflow lifetime. ## Use a hybrid deliberately Keep the revenue-critical saga orchestrated: payment, inventory, shipment, and compensation have one state machine. Publish durable facts such as `OrderConfirmed` and let search indexing, analytics, and notifications react independently. The orchestrator should not become a general integration hub; it owns one business process. Choreographed consumers should not emit commands that secretly control that process without appearing in its state. Use five decision questions: Is step order business-visible? Who owns timeout and compensation? Must operators see one authoritative state? Can consumers evolve independently? Does a new subscriber affect completion? Take one incident where engineers reconstructed a workflow from logs. Draw its transitions, owners, retries, and compensations. If nobody owns the full recovery, introduce a durable orchestrated state for the critical path. If the central workflow waits on optional observers, publish a fact and move those consumers back to choreography. ## Source references - -