In the last section, we saw how the Choreography pattern works. Each service acts independently, like dancers in a flash mob who all know the routine. It's simple when the dance is short. But what happens when the routine gets long and complicated?

This is where the second approach, Orchestration, comes in. Instead of a flash mob, think of a symphony orchestra. There's a conductor at the front, the orchestrator, who tells each section exactly when to play and what to play. The violins don't just decide to start; they wait for a command from the conductor.

For our ERP, this means we'd create a new service, maybe called the OrderFulfillmentSaga, that acts as the boss. When a new order comes in, this orchestrator takes charge. It sends a direct command to the Payment Service: "Charge this credit card for this amount." It then waits for a reply. If the reply is 'Success', it sends the next command to the Inventory Service: "Reserve these items." If the payment fails, the orchestrator knows immediately and can stop the process or run a compensating transaction.

The orchestrator keeps track of the entire process. It knows if the payment has been processed but the inventory hasn't been updated yet. This concept of tracking progress through a series of steps is called a State Machine pattern. The saga moves from one state to the next based on the success or failure of each command: AWAITING_PAYMENT -> PAYMENT_COMPLETE -> INVENTORY_RESERVED -> ORDER_SHIPPED.

This makes the entire business process explicit. All the rules and the flow of logic are in one place: the orchestrator. If you want to know how an order is fulfilled, you just have to look at the orchestrator's code. You don't have to hunt through five different services to piece the story together.

This leads to a fundamental difference in communication style. Choreography is based on events. An event is a statement of fact, like shouting "Order Placed!" into a room and letting whoever is interested react. Orchestration is based on commands. A command is a direct order to a specific service, like saying "Payment Service, charge this card."

The biggest advantage of orchestration is clarity. The business logic isn't scattered across multiple services; it's centralized in the orchestrator. This makes monitoring and debugging much simpler. If an order gets stuck, you can check the orchestrator's state to see exactly which step failed and why. This is a huge benefit when a network hiccup inevitably occurs, as we learned from the Two Generals' Problem.

Testing is also easier. You can test the entire order fulfillment workflow by triggering the orchestrator and watching it interact with mock versions of the other services.

However, this pattern has a significant downside: the orchestrator itself is a single point of failure. If the orchestrator service crashes, no new sagas can start, and existing ones can't proceed. It can also become a performance bottleneck if it has to manage thousands of concurrent business processes.

You're trading the potential chaos of choreography for the risks of centralization.

For complex, multi-step processes common in ERPs, the clarity and control offered by orchestration often outweigh the risks. It provides a single source of truth for your business logic, which is invaluable as the system grows.

Let's check your understanding of these core ideas.

Now that we've seen both choreography and orchestration, we can start to think about which pattern fits which scenario best.