# Choreography vs Orchestration > Choreography lets services react to events and decide their own next steps; orchestration gives an explicit coordinator responsibility for advancing a workflow. Choose choreography for independent reactions to business events, and orchestration when sequencing, deadlines, compensation, and a clear workflow status matter. Source: https://sysround.com/compare/choreography-vs-orchestration Updated: 2026-11-05 ## Side by side | | Choreography | Orchestration | |---|---|---| | Control flow | Distributed across event handlers | Explicit in a coordinator or state machine | | Communication | Usually published events and subscriptions | Commands and results over queues or APIs | | Workflow state | Spread across participating services | Progress tracked by the coordinator | | Coupling | Event schemas and implicit dependencies | Explicit workflow and command contracts | | Failure recovery | Local retries and event-driven compensation | Central retry, timeout, and compensation policy | | Observability | Requires correlated events to reconstruct progress | Explicit status, still needs worker tracing | | Scaling | Scale consumers independently; watch fan-out | Partition workflow ownership; scale workers separately | | Typical fit | Independent subscribers and simple event chains | Dependent steps and long-running workflows | ## The differences that matter The main difference is who owns the next step, not whether messages are asynchronous. With choreography, an InventoryReserved event might cause the payment service to act. With orchestration, a coordinator observes the reservation result and issues a payment command. Either approach can use durable queues. Choreography removes a central workflow dependency but does not remove coupling. Subscribers depend on event meaning, ordering assumptions, and other services producing the expected events. Orchestration makes those dependencies explicit, but changes to the business process often require changes to the coordinator. Failure handling becomes harder to follow as a choreographed chain gains branches, deadlines, and compensations. An orchestrator can persist which steps completed and decide what to retry or undo. Neither approach provides an atomic transaction across services: a refund is a new business action, not a database rollback. Both approaches need durable delivery, idempotent handlers, and a plan for crashes between local commits and message publication, often using an outbox. A durable orchestrator must also recover its workflow state and prevent conflicting owners from advancing the same instance. Centralized logic does not require a single server. ## Choose Choreography when - Several independent consumers react to the same business fact, such as analytics, notifications, and search indexing after an order completes. - The event chain is short, with few cross-service deadlines or conditional branches. - Teams need to add subscribers without changing the publisher or a central workflow definition. - Temporary subscriber lag is acceptable, and no single coordinator needs to decide whether the overall process succeeded. ## Choose Orchestration when - A business operation has dependent steps, conditional branches, or parallel work that must join before completion. - The system must answer exactly which step an order, transfer, or provisioning request has reached. - Deadlines, cancellation, escalation, or compensation must be enforced across multiple services. - Long-running work must resume after crashes without losing timers, completed-step records, or pending actions. ## Worked example: Ticket checkout with a payment deadline Suppose a ticket checkout holds two seats for five minutes, authorizes a $160 payment, and confirms the booking. If authorization times out, the payment may still have succeeded. An orchestrator records the hold ID, payment attempt ID, and deadline, then queries payment status or waits for a callback before deciding whether to confirm. If the hold expires first, it must resolve the late authorization, potentially by voiding it. Choreography can implement the same rules, but responsibility for timeout detection and compensation is spread across handlers. After confirmation, email and analytics can independently consume BookingConfirmed without becoming steps in the checkout workflow. ## In the interview - Start with the business invariant and draw one success path plus one failure path. Explain who decides the next step and who owns recovery. - For orchestration, describe durable workflow state, workflow IDs, timers, and safe ownership across coordinator replicas. Expect questions about crashing after sending a command but before recording its result. - For choreography, name the events and subscribers, explain how progress is correlated, and assign responsibility for detecting a stalled process. Expect questions about missing, duplicate, and out-of-order events. - Consider a hybrid: orchestrate the critical transaction lifecycle, then publish completion events for independent downstream consumers. Explain why those consumers should not block the core workflow. ## Common mistakes - Equating choreography with asynchronous messaging and orchestration with synchronous HTTP. Both can use queues, callbacks, and asynchronous results. - Claiming choreography eliminates coupling or orchestration necessarily creates a single point of failure. - Assuming either approach guarantees exactly-once side effects or atomic cross-service rollback. Retries, idempotency, compensation, and reconciliation still need explicit designs. - Adding a coordinator for every event reaction, or extending a choreographed chain until nobody clearly owns its deadlines and failure recovery. ## Interview questions where it comes up - [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Seat holds, payment outcomes, and expiration races require explicit ownership of workflow progress and compensation. - [Design a food delivery app like DoorDash](https://sysround.com/questions/design-doordash): Restaurant acceptance, courier assignment, and cancellation create a branching lifecycle that exposes the coordination trade-off. - [Design a video streaming service like YouTube](https://sysround.com/questions/design-youtube): Transcoding dependencies and publication gates benefit from explicit orchestration, while independent downstream reactions can consume events. - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Provisioning and upgrade workflows need durable progress, bounded retries, and recovery after controller failures. - [Design an on-call escalation system like PagerDuty](https://sysround.com/questions/design-pagerduty): Escalation deadlines and acknowledgement races require a clear owner for advancing or stopping the notification workflow. ## FAQ ### What is the difference between choreography and orchestration in microservices? Choreography distributes workflow decisions among services that react to events. Orchestration puts the overall sequence and progress tracking in an explicit coordinator. The distinction is ownership of control flow, not the messaging protocol. ### Is choreography or orchestration better for a saga? Both can implement a saga, where local transactions are followed by compensating actions when necessary. Choreography can fit a short, stable chain, while orchestration often makes branching, deadlines, and compensation easier to reason about. Neither makes intermediate states invisible or guarantees that compensation will succeed immediately. ### Can choreography and orchestration be used together? Yes. A coordinator can manage a critical workflow and publish business events for independent subscribers. For example, booking confirmation can be orchestrated while notifications and analytics react through choreography. ## Related concepts - [Workflow orchestration](https://sysround.com/concepts/workflow-orchestration) - [Saga pattern](https://sysround.com/concepts/saga-pattern) - [Event-driven architecture](https://sysround.com/concepts/event-driven-architecture) - [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency) - [Transactional outbox pattern](https://sysround.com/concepts/outbox-pattern) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.