Microservices Patterns: Orchestration and Choreography
Tags: microservices, beginners, architecture
Published: 2021-02-20 21:41:27

Hi everyone! This is my first post and I'd like to share some thoughts about the differences between *_Orchestration_* and *_Choreography_* as architecture approaches in a solution based on microservices. 

There are many ways to define the interaction between software components, in a microservices architecture, to have a robust result, is crucial to follow some [principles of design](https://dzone.com/articles/microservices-design-principles).

That is why could be a very important tool to know about *_Orchestration_* and *_Choreography_* terms.

## Orchestration
This pattern behaves like a real orchestra, where there is a central guider that coordinates all of rest of musicians in order to play a symphony. In *_Orchestration_*, a piece of software does that work and by certain number of calls, it makes possible the entire process.

![Alt Orchestration](https://dev-to-uploads.s3.amazonaws.com/i/f487zb7pxi0g7z83ve7b.PNG)

According to the last image, *service 1* is responsible for making the requests to other components. Those calls could be either synchronous or asynchronous. So, *service 1* manages the interactions between *service 2* and *service 3*. 

In that sense, an orchestrator becomes an easy way to manage complex processes by a centralized control between each steps. So, it has all required functionalities to make a response to the client.

Most likely, *_Orchestration_* can increase the dependencies between services. Due to the existence of a single coordinator of a entire process. Usually it is delegated to this component more responsibility than others and sometimes it results in a [lack of purpose and anemic model](https://www.martinfowler.com/bliki/AnemicDomainModel.html) .

### Summary
* A single component conducts all the process (orchestrator).
* Commonly, orchestrator has more responsibility that other components.
* Easy way to coordinate a complex process with several steps.
* If orchestrator gets so much responsibility, tends to anemic models.

## Choreography
On another side, *_Choreography_* is a pattern which components communicate by themselves to complete a request. So, there is no a single conductor but each service is responsible for doing its part of the job.  

The governance of services under this model could be more complex, since there are several points of failure. And evidently, it is necessary to complement the solution with a good tracing pattern.   

However, *_Choreography_* provides low coupling when is implemented under a event-driven architecture (although this approach is not exclusive of that pattern). Because of this, the components designed come to be more autonomous and it allows a better reusability thus the reduce of dependencies.     

![Alt Choreography](https://dev-to-uploads.s3.amazonaws.com/i/gtg3ndvkxhmije5orwae.PNG)

Therefore, in a choreography *service 1* doesn't know about the calls of *service 2* and *service 3*. 

### Summary
* Each service acts together to get a result with the same level of responsibility.
* The interactions flow uses to be more complex. 
* Components are more autonomous. 


## tl;dr
| Orchestration                                                      	| Choreography                                                    	|
|--------------------------------------------------------------------	|-----------------------------------------------------------------	|
| A single component conducts <br>all the process.                    	| Components have to act together in a coordinated way.                                        	|
| <br>Orchestrator has more responsibility <br>than other components. 	| Use to be a harder way to coordinate a <br>complex process with several steps. 	| 
| Orchestrator with so much responsibility<br>tends to anemic models. 	| Services show a tendency to be more<br>autonomous.                	|

## Conclusion
*_Orchestration_* and *_Choreography_* models have certain advantages and disadvantages and they are not good or bad by themselves. All depends on the requirements and technical capabilities. For that reason, it would be helpful to evaluate the pros and cons of both patterns to implement a solution that fits properly.
Finally, it is necessary to emphasize that is not kind of dichotomy between *_Orchestration_* and *_Choreography_* and they could be used in a sort of combination inside an software architecture.
 
## *_References_*

Bruce, M., & Pereira, P. A. (2019). Microservices in action. Shelter Island, NY: Manning Publications Co.