Orchestration vs Choreography in Microservices: Differences and Examples

Key takeaways

• Orchestration assigns workflow decisions to a coordinator; choreography distributes them among participants.
• Both approaches can use asynchronous messaging and both require explicit failure handling.
• Event-driven services still depend on contracts, delivery behaviour, and the meaning of published events.
• A hybrid design can coordinate mandatory steps while letting independent consumers react to the result.

Orchestration and choreography are two ways to coordinate work across microservices. With orchestration, a coordinator decides which operation should happen next. With choreography, participants react to events and determine their own next actions without one controller directing the entire flow.

Consider an order that requires a stock reservation and payment authorisation before it can be accepted. Email and analytics also need to know when acceptance happens, but they need not determine whether the order is valid. The coordination design should reflect those different responsibilities.

How Orchestration Works

An order coordinator requests a reservation, waits for its result, and then requests payment authorisation. It records progress and decides whether to accept the order, retry an operation, or begin recovery.

The orchestrator pattern gives those process decisions an explicit home. Inventory still decides whether stock is available. Payment still implements authorisation rules. The coordinator connects their outcomes according to the order workflow.

Commands can travel over HTTP or through a broker. An asynchronous command and its later result are still orchestration when the coordinator owns the decision to send the next command. The distinction concerns control, not whether the transport blocks a thread.

How Choreography Works

In a choreographed version, the order service publishes OrderSubmitted. Inventory reacts and publishes InventoryReserved. Payment reacts to that fact and publishes PaymentAuthorised. The order service consumes the result and applies the rule for accepting the order.

Microsoft’s choreography pattern describes distributing these decisions across participants. Each service owns its reactions and emitted events. The overall sequence emerges from the agreed relationships between them.

Choreography does not mean an absence of design or ownership. Someone still needs to establish which facts permit payment to proceed, how a rejected reservation is represented, and which service determines the customer-visible status. The workflow exists even when no single executable definition contains all of it.

Compare the Same Responsibilities

Concern	Orchestration	Choreography
Next action	A coordinator selects it from workflow state.	A participant selects it in response to an event.
Process changes	Often require changing the coordinator and affected contracts.	Can require coordinated changes across subscriptions and event meanings.
Overall progress	Usually represented in the coordinator’s durable state.	May require a projection or explicit business-status model.
Recovery	The coordinator sequences process-level recovery.	Participants implement recovery reactions and their dependencies.
Independent consumers	Can subscribe to events emitted by the workflow.	Fit naturally when each reaction can proceed independently.
Operational dependencies	Include coordinator workers and state storage.	Commonly include the broker and participating consumers.

Neither column guarantees better performance or availability. A coordinator can be replicated and partitioned by workflow instance. A choreographed system can bottleneck on its broker, a shared database, or one slow consumer. Assess the actual topology and workload.

Walk Through a Failure Before Choosing

Suppose stock is reserved but payment authorisation is declined. In the orchestrated design, the coordinator requests release of the reservation and records cancellation once the required recovery is confirmed.

In the choreographed design, a payment-declined event can prompt inventory to release the reservation. The order service also needs rules for how that event and the later release affect order status. If the release consumer is unavailable, the reservation does not disappear merely because an event was published.

Now consider a timeout instead of a decline. The payment outcome may be unknown. Both designs need a way to resolve that uncertainty before acting as though authorisation definitely failed. A different coordination style does not remove the possibility that a provider completed work but its response was lost.

Ask who investigates a stuck order, what evidence they inspect, and which action they may safely take. The answers often reveal more about the design than the successful path does.

Keep Event Contracts and Delivery Explicit

An event describes a fact, while a command requests an action. Naming a command SomethingHappened does not make consumers independent if everyone relies on one specific response to advance a hidden sequence.

Define event identity, business identity, payload meaning, and compatibility rules. An OrderAccepted event must have a stable meaning if several teams use it to trigger customer communication or reporting.

Publishing introduces its own failure window. A service can commit its state change and crash before sending the event. The transactional outbox pattern records an outgoing message with the local state change, then publishes it through a relay. The relay can publish more than once, so consumers still need duplicate handling.

These concerns also apply when an orchestrator sends commands through messaging. Durable coordination does not make message delivery or external side effects automatically exactly-once.

Understand Where Sagas Fit

A saga coordinates local transactions across services and uses compensating work when necessary. It can use either orchestration or choreography.

Compensation is a business response to partial success, not a shared database rollback. Releasing stock and cancelling a payment authorisation have their own conditions and failure cases. They may also run while other processes are changing related information.

The need for a saga therefore does not decide the coordination style. The question is where its progress and recovery decisions will be most understandable and maintainable for the team responsible.

Use a Hybrid Where the Boundary Is Clear

For this order, the team could orchestrate reservation and payment, then publish OrderAccepted. Email and analytics subscribe independently. A delayed analytics update would not change the accepted status.

Be precise about which outcomes are truly independent. If a notification is mandatory before a deadline, it needs tracked delivery and an owner even if it remains event-driven. Calling it a side effect should not hide a business obligation.

Use correlation identifiers to connect the order with its commands, events, and executions. Traces help explain individual executions, while durable business state explains whether the order has reached its required outcome.

Choose orchestration where branches, deadlines, and recovery benefit from an explicit process owner. Choose choreography where services can react to meaningful facts with limited dependence on one another’s completion. Draw that boundary around the workflow’s requirements, then examine what happens when each expected result is delayed, repeated, or absent.

The useful coordination choice is the one that makes responsibility clear when the expected next step never happens.