What are you looking for?

Orchestration vs Choreography

Learn about the benefits and disadvantages of using Orchestration or Choreography for your microservice architecture.
  • Blog
  • >
  • Orchestration vs Choreography

Wondering how to choose between Orchestration and Cheoreography for software development? Learn about the benefits and disadvantages of using Orchestration vs Choreography for your microservice architecture.

Orchestration and choreography are two different approaches for how to interact with other software components in a microservice architecture. Both have their benefits and drawbacks. This article should help you understand how these two approaches differ from each other, give some examples for each of them and explain how a clever combination of both can help you on your quest to build the best possible loosely-coupled system for your purposes. If you are already well aware of the foundations of these topics you can jump to the right point following the table of contents.

Table of Contents

Microservice Orchestration vs Choreography – what’s the difference?

Before being able to talk about benefits, drawbacks and use-cases we need to understand how those two approaches actually differ from each other. Let’s take a look at their definition and try to identify strengths and weaknesses after.  

What is Choreography

When talking about this pattern I always imagine a ballet in my head. Each of the dancers knows what they need to do and how to interact with each other. Everything happens implicitly, there is no need for a conductor.

Choreographed ballet dancers
Figure 1: Illustration of ballet dancers which are doing a choreographed dance

Transferring this into IT architecture, choreography refers to the coordination and organization of interactions between different software components or systems. It is a design pattern that enables the development of distributed systems where the components interact with each other through a set of well-defined interfaces, without requiring a central authority or coordinator.

A choreographed system uses by definition event-driven communication, whereas microservice orchestration uses command-driven communication. An event is something which happened in the past and is a fact. The sender does not know who picks up the event or what happens next. An example can be the event “Credit checked.”

Figure 2 shows a choreographed event-driven microservice architecture of a typical customer-onboarding process. It features five microservices for Registration, Credit, Address, and Criminal Check. Each of them communicated through events which are being exchanged through a message broker (e.g. Kafka).  

A choreographed event-driven microservice architecture
Figure 2: Event-driven choreographed microservice architecture for a customer onboarding use-case

Benefits of Choreography

After having explained the term itself let us take a closer look at the benefits of using a choreographed pattern for a microservice architecture. The most important ones are outlined in the bulleted list below:

  • Loose coupling: Choreography allows microservices to be loosely coupled, which means they can operate independently and asynchronously without depending on a central coordinator. This can make the system more scalable and resilient, as the failure of one microservice will not necessarily affect the other microservices.
  • Ease of maintenance: Choreography allows microservices to be developed and maintained independently, which can make it easier to update and evolve the system.
  • Decentralized control: Choreography allows control to be decentralized, which can make the system more resilient and less prone to failure.
  • Asynchronous communication: Choreography allows microservices to communicate asynchronously, which can be more efficient and scalable than synchronous communication.

Overall, choreography can be a useful design pattern for building scalable, resilient, and maintainable microservice architectures. Though some of these benefits can actually turn into drawbacks.

Downsides of Choreography

  • Complexity: Choreography can be more complex to implement and maintain than orchestration, as it requires the development of well-defined interfaces and the coordination of interactions between the microservices.
  • Lack of central control: Without a central coordinator, it can be more difficult to monitor and manage the interactions between the microservices in a choreographed system.
  • Lack of visibility: Choreography can make it more difficult to get a holistic view of the system, as there is no central coordinator that has visibility into all of the interactions between the microservices.
  • Difficulty troubleshooting: Without a central coordinator, it can be more difficult to troubleshoot issues in a choreographed system. So called event-chains can easily occur when multiple services are required for a certain domain. These are typically not visible and hence troubleshooting gets even trickier.

As you can see the event driven choreographed approach does not only lead to advantages and might not be a good fit for all scenarios. Hence it is important to carefully consider the requirements of your system when deciding whether to use choreography or another design pattern.

For more information on how you can tame an event-driven architecture visit Bernd Ruecker’s blog post, which is based on the customer-onboarding example from Figure 2.  

What is Orchestration

As the name already suggests, when talking about orchestration you can picture a big orchestra which features multiple instruments and a conductor who makes sure that everyone stays in tact. He tells when which instrument needs to play to ensure that the song sounds as it should like.

Illustration of an orchestra with its conductor
Figure 3: Illustration of an orchestra with its conductor

Orchestration refers to the coordination and management of the interactions and dependencies between different software components or systems. It is a design pattern that enables the development of distributed systems where a central authority or coordinator is responsible for managing and coordinating the actions of the different components.

An orchestrated system uses command driven communication. In comparison to the event a command has an intent. The sender wants something to happen and the recipient does not necessarily know who issued the command.

Let’s take a closer look at how an orchestrated microservice architecture could look like in a real use-case. Taking the example of an order-management process which involves checkout, payment, shipment in inventory services we need to add an overall order service which takes care of the orchestration. This is illustrated in Figure 4.

Orchestrated microservice architecture for an order management use-case
Figure 4: Orchestrated microservice architecture for an order management use-case

Benefits of Orchestration

Orchestration in microservice architectures can lead to some nice benefits which compensate for the drawbacks of a choreographed system. A few of them are explained below:

  • Simplicity: Orchestration can be simpler to implement and maintain than choreography, as it relies on a central coordinator to manage and coordinate the interactions between the microservices.
  • Centralized control: With a central coordinator, it is easier to monitor and manage the interactions between the microservices in an orchestrated system.
  • Visibility: Orchestration allows for a holistic view of the system, as the central coordinator has visibility into all of the interactions between the microservices.
  • Ease of troubleshooting: With a central coordinator, it is easier to troubleshoot issues in an orchestrated system.

Downsides of Orchestration

This pattern also also some general downsides. Let’s take a closer look at them and also try to find out how Camunda tackles them with their process orchestration platform.

  • Tight coupling: Orchestration is often perceived as being tighter coupled. But this is not true. Most discussions mix-in discussions about communication styles (like asynchronous communication) and assume orchestration using synchronous communication that leads to temporal coupling. But also with orchestration, a command itself could for instance also be transported via a message broker.
  • Single point of failure: The central coordinator in an orchestrated system can be a single point of failure, which can make the system less resilient. Though there is luckily the possibility of deploying the orchestrator in a high availability fashion.
  • Difficulty adding, removing, or replacing microservices: Changing the configuration of an orchestrated system can be more difficult, as it requires updating the central coordinator.
    • In the context of Camunda this is not necessarily true. By using the BPMN 2.0 standard it is very easy to change this configuration. It can be even easier than in a choreographed system. For more information on this topic I can recommend reading this article.
  • Overhead: The central coordinator in an orchestrated system can add overhead to the system.

When to use Orchestration vs Choreography

Whether you want to use choreography or orchestration in your microservice architecture should always be a well-thought-out choice. Both approaches bring their advantages but also downsides.

Before taking a look at how these two patterns can be mixed to get the best of both worlds, let us take a look at scenarios for either choreography or orchestration.

Scenarios for using Choreography

The perfect scenario for using event-driven communication is when the message leaves the context of the current domain. Taking the example of a customer onboarding process this could for instance happen when enrolling this person for a newsletter or bonus program. This is happening outside the core context of customer onboarding and we do not necessarily need to wait for an event to return in order to proceed with the overall onboarding flow. Hence we do not require any visibility in that area.

This approach is particularly useful when …

  • … you want to avoid creating a single point of failure or bottleneck
  • … you want to give microservices more autonomy and independence
  • … you want to make it easier to add or remove services from the system without disrupting the overall flow of communication.

Scenarios for using Orchestration

When you are facing domain coupling between your services orchestration is the way to go. This occurs when business capabilities require multiple services which depend on each other. Orchestration makes it easier to maintain visibility and helps troubleshooting the system in case of an error. Especially when thinking about a complex architecture featuring dozens of services this results usually in a very sustainable approach.

Using orchestration is especially helpful when …

  • … you need to guarantee a specific order of execution for a set of microservices
  • … you want to manage the lifecycle of microservices execution, such as starting and stopping them
  • … you want a centralized control over the interactions between microservices, to have a unified view of the system, and make it easier to troubleshoot and make decisions.
  • … you have a complex system with many interdependent microservices, and you need to ensure that each service is working optimally and that all the services are working together in a coordinated way.

Mixing Choreography and Orchestration

Mixing choreography and orchestration in a microservice architecture can provide several benefits. Choreography allows for flexibility and autonomy in the interactions between microservices, as each service can communicate directly with other services without needing a central authority. This can lead to more decentralized and resilient systems. On the other hand, orchestration can provide a centralized approach to controlling and coordinating the interactions between microservices, which can simplify the management and troubleshooting of the system. By combining both approaches, a microservice architecture can gain the benefits of both flexibility and simplicity.

Mixture of Choreography and Orchestration in a Customer Onboarding microservice architecture
Figure 5: Mixture of Choreography and Orchestration in a Customer Onboarding microservice architecture

How to choose between Orchestration vs Choreography

Deciding between Choreography and Orchestration requires careful consideration, as both have advantages and disadvantages when it comes to your microservice architecture. Regardless of whether you choose one, both, or a mix of the two, it’s important to understand your needs and what you hope to get out of it.

Orchestrate your microservices today

At Camunda, we can help you get started with microservice orchestration today. Learn more about how it can help your microservice architecture.

Orchestrate more than microservices

Process orchestration can have a positive impact on your business beyond even microservice orchestration. Learn more about how Camunda Platform 8 can help you orchestrate any process and be sure to take advantage of our free trial.

Start the discussion at forum.camunda.io

Try All Features of Camunda

Related Content

Overcome many of the challenges of a monolith-to-microservices migration with process orchestration.
Easily orchestrate different departments and end-user requirements for risk assessment with AI and decision modeling.
Fully realize the advantages of process automation while avoiding the most common pitfalls of implementation.