When should you choose choreography vs orchestration for your Microservices Architecture


Choreography and Orchestration are fantastic ways to manage the interactions, communication and behaviour between your Microservices and often there is not a one size fits all approach you should take, just because you have taken one of these approaches in a previous solution does not mean that it the right approach for your next, hopefully this post will be able to give you a high level overview on what you should consider and help you to mange your Architecture decision.

Before you start

About this post:

  • 5 – 10 min average reading time
  • Suitable for intermediate through to advanced

What you will gain reading this post:

  • An overview of the choreography and orchestration
  • An understanding of the challenges that they each present
  • A guide on choosing the best pattern to support your solution

What you can do to help support:

  • Like, comment and share this article
  • Follow this blog to receive notifications of new postings

Now, let’s get started.

Choreography

What is choreography of Microservices?

Choreography is simply the distribution and decentralisation of decisions, logic and interactions between services. Choreographies most common pattern relies on broadcasting data known as events in which any service that is interested in that data can consume it and perform the action that they are tasked to do. The service/s should not require instructions on how to behave and should be self aware on what they need to do, they in turn have a brain of their own rather than being controller by a centralised brain.

Benefits

It provides low coupling of services in which you can add/remove services into your solution without impacting other services in your overall solution.

Moves away from a Monolithic approach, working better with Agile delivery teams.

CRUD and SAGA patterns are supported.

Challenges

The business process will be spread across multiple services making it difficult to maintain, manage and see the overall business process.

Transactions will become more granular making management of the transaction specifically around error handling and rolling back much more difficult.

It requires a change in mindset.

Choreography service flow Diagram
Choreography component Diagram

What are good use cases for a choreography approach?

  • Systems that don’t require up front validation.
  • Systems that don’t require synchronous requests and responses.
  • Systems that don’t require client blocking behaviour.

While these can be solved with various other techniques using choreography e.g. CRUD, multiple calls, reactive as well as others it does require a mind set change and a different way of interacting.

Orchestration

What is orchestration of Microservices?

Orchestration relies on having a centralised service referred to as the orchestrator or process flow engine, the so called brains for calling services to perform specific actions and expecting the response back to the centralised service for it to make decisions on the next course of action.

Benefits

Easy to manage and maintain the business process as all the logic is located in a single central location.

Services that are called don’t require decision logic, they will be able to perform an action and return the response.

Managing and maintaining the state, processes and monitoring is easier.

Processes requiring Human interactions can be easily supported.

ACID, SAGA and CQRS patterns are supported.

Challenges

Services are highly coupled to the orchestrating service with the orchestrating service requiring connection information about the services built into the requesting tasks.

Ultimately the centralised service is a single point of failure.

Difficult to seperate work across multiple Agile delivery teams.

Typically the centralised service is referred to an a monolithic.

Orchestration flow Diagram
Orchestration component Diagram

What are good use cases for an orchestration approach?

  • Systems that require up front validation.
  • Systems that require synchronous requests and responses.
  • Systems that require client blocking behaviour.

Hybrid

What do you mean by Hybrid?

Hybrid is a combination of a centralised service that makes the decisions and manages the business process (orchestration approach) however the communication to other services are performed through events (simplified choreography approach).

Benefits

Easy to manage and maintain the business process as all the logic is located in a single central location.

Services that are called don’t require decision logic, they will be able to perform an action and return the response.

Managing and maintaining the state, processes and monitoring is easier.

Processes requiring Human interactions can be easily supported.

ACID, SAGA and CRUD are supported.

Challenges

It is a more complex solution to implement, incurring the usual costs of implementing a complex solution.

Ultimately the centralised service is a single point of failure.

Typically the centralised service is referred to an a monolithic.

It requires a change in mindset.

Hybrid component Diagram

What are good use cases for a Hybrid approach?

  • Any of the systems mentioned above under the Choreography and Orchestration sections

Conclusion

Microservice interactions decision Diagram

Consideration 1 – Centralised Business Process Model

The most important consideration is where you want to capture the business processes, if you are keen to have that managed in a centralised location then orchestration or a hybid solution is the best approach to take, however if you are happy for a distributed business process then choreography will be the best approach.

Consideration 2 – Service Coupling

Is it important that you have services that are self managing and are not dependant on who is calling them, if your main requirement is to have a loosely couple solution then choreography will be a good approach, if that is not a key consideration in your solution then orchestration or hybrid would be a good approach.

Consideration 3 – Transaction Management

How do you want to manage the transaction? and I think the most important question is how do you want to handle transaction errors, do you have state to rollback, do you have data to rollback, if that is the case then SAGA may be an important consideration, all solutions easier support SAGA, however my experience is that orchestration is easier to manage the SAGA pattern rather then choreography.

Consideration 4 – Client Blocking

Do you want to fail fast? Do you want to validate you data on receiving the request and inform the sender of any errors that has occurred upfront? Do you want to want the client to wait for a response or can you fire and forget? Typically this is controlled via Asynchronous vs Synchronous requests / events, if you require Synchronous requests it would be better to use orchestration or hybrid, if you are however only dealing with Asynchronous requests / events then choreography would be a good solution.

Result

My experience is that you can achieve the results and solutions you are looking for via either choreography or orchestration, however based on requirements you can make the solution less complex, easier to deliver and easier to support, with the suggested above I am hoping you will be able to pick the best option based on the requirements you are supporting.

Lastly… please leave your experiences, thoughts and opinion in the comments section below, I would love to hear what you think.

Resources

Saga – https://microservices.io/patterns/data/saga.html

CQRS – https://microservices.io/patterns/data/cqrs.html

Author: Robert Leggett

I am an experienced and passionate leader that enjoys educating and contributing to the technical community. I love to converse in Spanish, play video games and spend time with my family.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.