Happy paths only exists in YouTube tutorials

In the real world, you need "something" in charge—an orchestrated approach.

Thank you to our sponsors who keep this newsletter free:

Multiplayer auto-documents your system, from the high-level logical architecture down to the individual components, APIs, dependencies, and environments. Perfect for teams looking to streamline system design and documentation management without the manual overhead. 

Software architecture would be easy if the world only had happy paths. But, of course, real-world applications are almost always complex.

They have many moving parts, paths, and services that must interact under variable conditions—even when things don't go smoothly.

This is where Orchestration can work to reduce the complexity.

What is Orchestration?

Orchestration is about coordinating the execution of distributed services to complete a business process.

Think of it as a central "conductor" managing how different services work together to fulfill a task. It's often used when many independent services need to interact, and this type of coordinated process is sometimes called an "Orchestrated Transaction."

Sketched using Multiplayer

Why Do We Need Orchestration?

In modern software systems, especially those built with microservices, workflows usually require multiple services to cooperate. Each service may handle different data and logic, and without a central manager, managing the interactions becomes very complex and error-prone.

Orchestration simplifies this by introducing a centralized control mechanism—The Orchestrator. This mechanism:

• Manages the Workflow: Ensures services are called in the correct order.

• Handles Errors: Provides retries and alternative flows when needed.

• Keeps State: Maintains the state of the workflow, such as what has been completed and what still needs to be done.

Key Features of Orchestration

1. Centralized Control: The orchestrator serves as a single decision-making point for workflows. It ensures services are invoked correctly, handles retries, and manages the state.

2. Service Interaction: The orchestrator coordinates the data flow between different services. This can be done in either a synchronous (waiting for a response) or asynchronous (not waiting for a response) manner.

3. State Management: The orchestrator keeps track of where the workflow stands, which is crucial for managing complex systems and ensuring consistency.

4. Error Handling and Compensation: Orchestration provides sophisticated mechanisms for managing errors. If something goes wrong, it can:

   • Retry the failed step.

   • Use an alternative approach to complete the task.

   • Or Rollback earlier actions to ensure consistency.

A Practical Example: E-commerce Order Workflow

In this example, we explore how orchestration can manage the workflow of an e-commerce system involving many services.

For this example, we will focus on

• Orders

• Shipping

• Notifications

• Payments

How the Happy Path will look like

1. Client Places an Order: The process begins when the client sends a "Place Order" request to the Order Orchestrator.

2.  Order Creation: The Order Orchestrator receives the request and forwards it to the Orders Service to create the order. The Orders Service processes the request and creates a new order record in its database.

3. Shipping Request: Once the Orders Service confirms the order creation, the orchestrator asynchronously calls the Shipping Service to start the shipping process. This is done because shipping the order takes time and doesn't need to block the workflow.

4. Order Shipped: The Shipping Service processes the shipping request. After the order is shipped, it notifies the orchestrator about the successful shipment.

5. Order Status Update: Upon receiving the shipping confirmation, the orchestrator updates the order's status to "Shipped" in the Orders Service.

6. Notification: Finally, the orchestrator calls the Notifications Service to send a Success email notification informing the client that their order has been shipped.

Sketched using Multiplayer

How the Not-so-Happy Path will look like (Alternative Workflow)

1. Client Places an Order: The client sends a "Place Order" request to the Order Orchestrator.

2. Order Creation: The Order Orchestrator forwards the request to the Orders Service, which creates the order.

3. Shipping Request: The orchestrator asynchronously calls the Shipping Service to start the shipping process.

4. Backorder Notification: The Shipping Service finds that there is not enough inventory to fulfill the order and notifies the orchestrator about the backorder status.

5. Order Status Update: The orchestrator updates the order's status to "BackOrdered" in the Orders Service to reflect the issue.

6. Notification: The orchestrator calls the Notifications Service to send a backorder notification to the client, informing them about the issue with their order.

Sketched using Multiplayer

How the Failed Path Will Look Like (Compensating Transactions)

When an error occurs during a transaction, it may be necessary to undo previously completed steps to maintain system consistency.

We called these compensating transactions. For example, in systems with no support for backorder, this will look like this:

1. Client Places an Order: The client sends a "Place Order" request to the Order Orchestrator.

2. Order Creation: The orchestrator calls the Orders Service to create the order.

3. Shipping Request: The orchestrator calls the Shipping Service to process the shipment.

4. Inventory Issue: The Shipping Service detects insufficient inventory to fulfill the order and notifies the orchestrator.

   • Compensating Transactions Initiated:

5. Cancel Order: The orchestrator calls the Orders Service to cancel the order.

6. Revert Payment: If payment was processed, the orchestrator might need to send a message to the Payment Service to refund the amount to the client.

7. Order Status Update: The orchestrator updates the order's status to "Cancelled" in the Orders Service.

8. Notification: The orchestrator sends a cancellation notification via the Notifications Service.

Sketched using Multiplayer

Like everything in Systems Design, Orchestration comes with trade-offs.

Let's talk about it:

Benefits:

• Centralization: All workflow management is handled from one place, simplifying logic and making it easier to manage.

• Retries and Resilience: The orchestrator can automatically retry failed services, making the system more robust.

• State Visibility: The orchestrator maintains the state, which helps with monitoring, debugging, and understanding the workflow’s progress

Drawbacks:

• Potential Bottlenecks: Since all communication must go through the orchestrator, it can slow things down if overwhelmed.

• Single Point of Failure: If the orchestrator goes down, the entire workflow stops. This can be mitigated by adding redundancy and load balancing.

Key Takeaways

• Orchestration simplifies managing workflows by centralizing control and handling retries, states, and errors.

• The orchestrator can slow down the system if it becomes a bottleneck, so it’s important to use redundancy.

• Asynchronous orchestration allows multiple tasks to run in parallel, improving scalability.

In simple terms, orchestration means having something in charge that knows the whole workflow. If any problem occurs, the Orchestrator can take action or at least notify about the failure.

What About You? How have you handled complex workflows?

---

System Design Classroom is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

---

Articles I enjoyed this week

• Eventual Consistency is Tricky by

  Saurabh Dashora

• 8 effective debugging strategies to find and fix bugs like a pro by

  Petar Ivanov

• How I STOPPED Failing Coding Interviews by Ashish Pratap Singh by

  Ashish Pratap Singh

• 9 Tools To Develop Software For Cloud by

  Marcos F. Lobo

---

Thank you for reading System Design Classroom. If you like this post, share it with your friends!