Let Your Microservices Dance – Orchestration vs Choreography

Introduction :-

The Microservice Architecture is a collection of small services with each service having a specific function. Application and business use case is broken up into a set of composable services which promise many technical benefits to enterprise organizations. They are small, lightweight, easy to implement, enable reusability that reduces the cost of developing or changing applications, ensures the efficient use of resources, and makes it easy to scale applications on demand.

Business Context :-

These service modules can not perform well in isolation and need some medium so that they interact and share data. At a high level, there are two approaches to getting microservices to work together toward a common goal: Orchestration and Choreography.

Orchestration or Choreography are fascinating patterns. They are fantastic ways to manage the interactions, communication, and behavior between microservices, however there is not a one size fits for all . These 2 concepts are like Orchestra and Jazz. Consider the example of filling gas in a car. A high level workflow might look something like this:

1. Swipe the card
2. Select the variant
3. Based on availability , gas will be dispensed
4. Fill the car tank.
5. Take the Receipt

Let’s split the components up , into 3 parts:

1. Payment — This is when the card is swiped, and in the end the receipt is issued.
2. Grade Selection — Person can select the gas variant, against price. At code level, think of this component being backed by the merchant database.
3. Gas Dispense — Responsible for dispensing gas, based on selection.

Choreography:-

In a typical Jazz band, there is no conductor, players will improvise other players. Everyone typically knows what they are supposed to be doing, and is required to hit the right notes, as each beat hits. This is exactly how each bounded context work together in choreography.

For the above components to have choreography, they would emit an event for every action that was executed on. The architecture would look something liker below :-

Choreography is driven by events from the various services within a system. Each service consumes events, performs an action, and publishes events. In this pattern, each bounded context would register the events they’re interested in. Whenever this event is emitted, the bounded context takes the event and performs certain actions, then emit another event based on the change. Each component only knows about things that they are interested in.

Orchestration:-

In an orchestra, each musician is awaiting command from the conductor. They are each an expert at playing their instrument, whether it be a violin, bass drum or clarinet, have the sheet music for their part ,however they’d be collectively lost without the conductor.

This is similar to the orchestration pattern in the sense that typically there would be a process manager (conductor) that handles all incoming events. It would know what to do with every event. It then converts the event to a command and sends it to the relevant bounded context.

With the same example, an orchestration pattern would look something as highlighted below :-

An extra Orchestrator component is introduced compare to choreography. This component is sometimes also called Process Manager. It is responsible for all the events from all bounded contexts that are responsible for a particular scenario. In this case, the whole system. Whenever an event is received, it converts this event to a command and sends the command to the relevant bounded context. In this pattern, each bounded context now knows nothing about any other. In fact, it doesn’t even need to know about Orchestrator, however Orchestrator knows the entire process.

Conclusion :-

RESTful API-only approach is getting old , for architecture that delivers business services faster and more reliably, and that scales with ease. Orchestration and choreography don’t have to be mutually exclusive. The rule-of-thumb ,when it comes to implementing business workflows would be to use orchestration within the bounded context of a microservice,  but use choreography between bounded-contexts. The main point to remember is to try and minimize/remove direct point to point communication between the business services.