A case for adopting process-based Choreography

Information chains can be visualised as process flows consisting of a number of (consecutive) steps. Business Process Modelling Notation (BPMN) is commonly used for this purpose as it can easily be understood by both customers and systems experts. Whilst the steps in an information chain may be simple enough, implementing them using a microservices architecture in a robust and flexible way is a trickier business. 

As systems become increasingly complex, knowing how best to maintain and grow them becomes a critical challenge. Traditional approaches like orchestration and choreography offer distinct advantages but also present trade-offs. In this post, we delve into the intricacies of these two approaches, exploring their advantages and disadvantages. Moreover, we introduce a hybrid model known as process-based choreography, which seeks to harness the best of both worlds.

Orchestration

Imagine you’re at your local bakery, buying bread. It’s a popular place, so they use a ticketing machine as part of the ordering process. As you enter the store, you collect a ticket and then wait until that number is called before going to the counter to be served.

This, in a nutshell, is how the orchestration approach works. The flow itself is closely related to the design - there’s a process manager that controls the process and ensures the steps are executed in the right order. 

In systems that use orchestration, each service knows what it should do, but it doesn’t know when to do it. This creates a lack of flexibility.

Here are the pros and cons:

• [+] The process is simple
• [+] Centralised control: the process manager knows the current state of the process flow
• [+] The process execution is visible as the process manager always knows the current state and can easily communicate this information to stakeholders
• [+] Ease of troubleshooting
• [-] Tight coupling between the process manager and the microservices reduces flexibility, increases complexity, limits scalability, decreases reliability, complicates deployment
• [-] The process manager is a single point of failure
• [-] More difficult to do updates in the system
• [-] Overhead: the process manager can become a bottleneck, increasing latency and resource consumption while complicating error handling and scalability

Choreography

Now imagine you’re at the market. You stop at the vegetable stall and ask the people in front of you who is last in line. Once that person has been served, you know it’s your turn. 

In this scenario, we are describing how the choreography approach works. There is no process manager that directs the flow to each service—each service is responsible for its own execution.

In systems that use choreography, each service knows what it should do and when to execute, so services act autonomously. This creates a lack of visibility of what’s happening in the flow.

The pros and cons:

• [+]  Loosely coupled: the microservices are deployed independently from each other
• [+]  Ease of maintenance: having a loosely coupled system has the benefit of making it easier to update one part of it
• [+]  Decentralised control
• [+]  Asynchronous communication: it allows microservices to operate independently and handle varying loads more effectively, improving scalability, resilience, and overall system performance
• [+]  Flexibility
• [-] Complexity
• [-] Lack of centralised control
• [-] Lack of visibility: as all microservices act without a central coordinator, it’s less clear what the current status of the process flow is
• [-] Difficulty troubleshooting

The best of both worlds

Neither of these approaches is the holy grail - the advantages of one tend to be the disadvantages of the other. But what if you could combine them?

• When designing how the system works, it’s important to draw process flows that customers will understand. This means that the orchestration view is more appropriate.
• When implementing a process flow, you want to break it up into steps, allowing each to be updated independently from the others. The choreography approach works best here.
• Finally, when it comes to giving feedback to users and customers about the execution of the process, it’s good to return to the orchestration view to show which of the services failed. 

Combining the two approaches can be achieved by using BPMN orchestration visualisation techniques and working out what the precondition is for each step in the process. Once a service knows under which preconditions it may execute its logic, it can work independently from the other services, and so it becomes choreography-based. Furthermore, incorporating observability tooling makes execution more visible and easier to troubleshoot.

We refer to this hybrid approach as process-based choreography. Determining the service preconditions ensures that the execution will be according to design and can be visualised as a presentation layer on top of the individual services.

Conclusion

System design often involves sacrificing one feature for another, and the age-old trade-off between control and flexibility. Process-based choreography offers a compelling solution by seamlessly blending the strengths of orchestration and choreography. By defining clear preconditions for each service within a well-structured process flow, we can achieve both the visibility and control of orchestration while maintaining the flexibility and scalability of choreography. This hybrid approach empowers organisations to build systems that are not only efficient and reliable but also adaptable to evolving business needs and technological advancements.