Reading Notes: Choreography vs Orchestration in Event-Driven Architecture

Reading notes from "Practical Event-Driven Architecture".

Event-Driven Architecture (EDA) is about building systems that react to events rather than relying on direct requests. Instead of tightly coupled API calls, services communicate by publishing and subscribing to events, making systems more scalable, resilient, and loosely coupled.

But when multiple services must work together for a business flow, like processing an order, how do we coordinate them? That is where two common patterns come in: choreography and orchestration.

1. Choreography: Everyone Knows Their Dance

In a choreographed system, there is no central controller. Each service listens to specific events and reacts accordingly, producing new events in response.

Concept:

• Each service subscribes to events it cares about.
• When it receives an event, it performs its action and publishes another event (if needed).
• The flow emerges naturally through the chain of events.

Example: Order Processing

• Order Service publishes OrderCreated.
• Payment Service subscribes to OrderCreated, charges the customer, and publishes PaymentCompleted.
• Inventory Service listens to PaymentCompleted, reserves items, and publishes InventoryReserved.
• Shipping Service listens to InventoryReserved, prepares shipping, and publishes OrderShipped.

Flow:

OrderCreated -> PaymentCompleted -> InventoryReserved -> OrderShipped

Pros:

• Very loosely coupled. Each service only knows about event types.
• Easy to add new services without touching existing ones.
• Great for scalability and evolutionary growth.

Cons:

• Harder to visualize or debug end-to-end flows.
• No single place to manage the process logic.
• Risk of unexpected event loops or missing steps if not well designed.

When to use:

• Your domain flow is simple.
• Each service can act independently.
• You want high autonomy and flexibility.

2. Orchestration: The Conductor Leads the Orchestra

In orchestration, there is a central controller, the orchestrator. It coordinates the flow of events and calls the necessary services.

Concept:

• A central orchestrator (for example, Order Orchestrator) sends commands or triggers to other services.
• Those services perform actions and respond with events.
• The orchestrator listens to those responses and decides the next step.

Example: Same Order Flow, Orchestrated

• Order Orchestrator receives a new order and sends ProcessPayment.
• Payment Service processes payment and emits PaymentCompleted.
• Orchestrator listens and sends ReserveInventory.
• Inventory Service reserves items and emits InventoryReserved.
• Orchestrator listens and sends ShipOrder.

Flow:

Orchestrator <-> PaymentService <-> InventoryService <-> ShippingService

Pros:

• Easier to monitor and visualize the business process.
• Centralized error handling and retries.
• Easier to enforce business rules and dependencies.

Cons:

• The orchestrator can become a single point of control (or failure).
• Reduces the autonomy of microservices.
• Harder to scale horizontally if not designed carefully.

When to use:

• The business workflow is complex or sequential.
• You need clear visibility and control.
• Error handling and compensation logic matter (for example, payment or booking systems).

3. Choreography vs Orchestration: Quick Comparison

4. Hybrid Approach in Practice

In real systems, you often combine both patterns.

For example:

• Use choreography for independent actions (sending notifications or updating analytics).
• Use orchestration for critical flows (payment, booking, refund).

Example: An Order Orchestrator manages the main order process, but once the order is shipped, a Notification Service listens to OrderShipped independently to send an email. That is choreography.

5. Takeaway

Choreography gives you freedom and flexibility. Orchestration gives you structure and control.

In Practical Event-Driven Architecture, the key insight is that neither is universally better. The right pattern depends on your business domain complexity and team maturity.

Design your events like contracts, keep them meaningful, and choose your coordination style with purpose.