Microservices architecture can be considered as a small set of services, each with its own life and functions. These services can function in isolation without any issues, but sometimes they need to interact with the external world. It is at this point that we ask ourselves: Orchestration vs Choreography in Microservices?

Let’s begin by defining each one:

Orchestration Architecture in Microservices

In musical orchestras, the conductor guides all the musicians to achieve a common goal; if we apply this concept to a microservices architecture, we would have a central controller that manages all interactions and orchestrates them.

We could say that it is a centralized system, where I call you and wait for your response, in order to transmit it further.

Advantages of Orchestration Architecture in Microservices:

• Simpler and easier to maintain.
• Provides a good way to control the flow of the application in synchronous processes.

Disadvantages of Orchestration Architecture in Microservices:

• Creates dependencies between services, as waiting for the response from service A can cause bottlenecks.
• Having a single orchestrator for all requests introduces a single point of failure. If the orchestrator goes down, the entire system is affected.
• Synchronous communication for all requests can result in increased response time, as it accumulates the response time of each service involved. Asynchronous systems can mitigate this issue, but transactional compensation mechanisms need to be considered.
• In microservices, the goal is to create decoupled and independent services, but this architecture introduces tight coupling between services.

Choreography Architecture in Microservices

On the other hand, we have a choreography architecture, which we can imagine or compare to a dance, where each dancer performs their own movements independently.

Choreography Architecture in Microservices

If we apply this concept to microservices, it is exactly what we aim to achieve, that is, isolation and avoiding dependencies.

In this type of architecture, the goal is to have all implemented services work independently, which is one of the issues in orchestration architecture.

Generally, each service does not require any instructions to function. A decentralized system is sought, often functioning based on events, with services subscribing to those events. This approach is also known as reactive architecture, which allows for reactive architecture.

Advantages of Choreography Architecture in Microservices

• Typically, development in this architecture is more agile and allows for greater decoupling, so if a service needs to be removed or goes down, it won’t affect the entire system.
• System control is distributed, eliminating a single point of failure.
• It works well in agile models where teams can take charge of different microservices.
• Enables the use of event-driven design patterns such as Event Sourcing or the Command Query Responsibility Segregation (CQRS) pattern.

Conclusion

In this post about orchestration vs choreography in Microservices, we have discussed the advantages and disadvantages that can arise when choosing either of these architectures. Both architectures are equally valid, and the choice between them depends on the specific scenario.