Microservices are all the rage right now. They allow you to split apart your app into small chunks with clear domain boundaries. Microservices are decoupled from each other, allowing them to be changed and deployed independently of one another, which provides greater autonomy to the teams working on each microservice. They also provide easier ways to scale heavily-used parts of the app without having to scale up the entire monolith.
It’s easy to see why microservices are appealing. However, microservices also bring with them a lot of complexity, from data consistency to communication to logging to service discovery.
It’s the challenge of communication between microservices that I’d like to address today.
Two Modes of Collaboration
What do you do when microservices need to talk to each other? Ideally all communication should be asynchronous. Additionally, any sort of interactions between microservices should not tightly couple them together. Otherwise, you lose out on the benefits of independent changes and deployments.
There are two main modes of collaboration we can reach for: orchestration (request/response) or choreography (event-driven).
With orchestration, or the request/response pattern, a central service tells everything what to do. It makes requests to other downstream services to ensure that all the right things happen, and the downstream services respond to these requests.
With choreography, or event-driven architecture, the first service simply emits an event. Various services can subscribe to these event channels, and when they see a particular event emitted, they can respond however they would like.
An Example: E-Commerce Checkout
Let’s consider an example to better understand these two paradigms.
Imagine we have an e-commerce site. When a customer completes the checkout process, a few things need to happen:
We need to send an email to the customer with their order confirmation.
We need to send the order to our warehouse so we can begin the shipment.
If the customer signed up for our rewards program, we need to create a new points balance for them.
It’s important to note that once an order is placed, these next three tasks don’t necessarily need to happen in any particular order, they just need to happen.
Our checkout service will handle the initial interaction with the customer. Our three downstream services are an email service, a warehouse service, and a rewards service. Our email service will handle sending the email, our warehouse service will handle fulfilling the order, and our rewards service will handle creating the new points balance.
So what would the process look like for orchestration and for choreography?
Orchestration
With an orchestrated process, the checkout service would act as our central service. When the customer submits their order, the checkout service would then make three API requests to the email service, warehouse service, and rewards service. The checkout service would tell the email service to send an email, the warehouse service to started preparing the shipment, and the rewards service to create the new points balance.
In this sense, the checkout service acts as the conductor of an orchestra, telling all the players what to do and when.
Choreography
With a choreographed or event-driven architecture, the business process is the same, but the way our services handle it is slightly different. When the customer submits their order, the checkout service would emit an event. This even would be called something like “OrderCreated” and would include the order details.
Our three downstream services (email, warehouse, and rewards) would be subscribed to an event channel and listening for events. When the “OrderCreated” event is emitted, our three services would see the event and respond accordingly by sending the email, preparing the shipment, and creating the new points balance.
In this sense, our services act as dancers in a ballet, each independently dancing their part as they respond to the music.
Downsides of Orchestration
Did you catch the difference here? It’s subtle, but important. The main difference is that choreography, or event-driven architecture, provides us with more flexibility when our app needs to change.
What if, for example, later down the road we’ve created a fourth service, and this also needs to do something when an order is placed? In an orchestrated model, in order to change our app, we would need to modify our checkout service to make a fourth API request to this new service.
Or what if the API endpoint to one of our existing three services has changed? Maybe rather than calling the original endpoint, we need it to call a different endpoint? Or maybe we need it to make two API requests to the service rather than one? In an orchestrated model, changes of this sort would again require us to modify the checkout service.
We’ve inadvertently coupled our microservices together!
Benefits of Choreography
Now, think back to the choreographed architecture. The checkout service simply emits an event, and all the downstream services simply respond to the event.
So, need to add a fourth service to the mix? No problem, just have it subscribe to that event.
Need to change how an existing service responds to the event? No problem, we are capable of changing a downstream service’s behavior without affecting any of the other services like the checkout service.
Choreography allows us greater flexibility and helps us keep our services decoupled.
Top comments (5)
I disagree with your downsides and benefits. In the majority of the situations, the outcome is precisely the opposite. Choreography makes it extremely hard to evolve services as opposed to orchestration.
Imagine a situation when the order-created event schema changes. Discovering which services will be affected by the change is already very hard. Deploying such change into production is only possible if you deploy all the services as a single unit, invalidating all the microservice architecture benefits.
Even in your diagrams, the orchestration represents the whole transaction, but just a single step in the case of choreography. The whole diagram would be a mess if all the reply messages are included.
Orchestration allows services to have very clear APIs and not depend on other services directly. Only the orchestrator should know about all the services participating in the business transaction. In the case of choreography, every service potentially depends on any other service, and there are no explicit APIs. Event schemas are the best you can get but are far from real APIs like gRPC.
The only time choreography is reasonable is when events are fire and forget. So there is no workflow from the business point of view. E-commerce is the exact opposite of this case. You cannot ship an order without waiting for payment and a fraud check to complete.
I talk from my experience. I was for many years a tech lead of the Amazon Messaging platform and built multiple PubSub systems. AWS SQS still runs on the storage I initially designed and implemented. So I was an advocate of choreography. But with time, I learned that it was a mistake to rely on it for building microservice-based architectures. By the way, Amazon order fulfillment is implemented as orchestration.
this is a complicated scenario for both approachs.
Both approaches allow clear API
So you are basically saying about coupling. What if your business transaction consist of independent/concurrent sub-transactions or even no business transactions, but a stream of events to process instead?
In choreography - you got those fire and forget most of the time
Order fulfillment - very common scenario - a sequence of state transitions though predefined steps/graph. Go with orchestration, unless you have dozens of services handling stream of events in a different way concurrently. Not all scenarios are like changing a state from A to B and finally C sequentually.
don't forget to monitor the event service or everything stops here
and then monitor the monitoring service, and the monitor the monitoring of monitoring...
Haha yep, it's turtles all the way down...
I really get confused with this terms Orchastrator vs choreography .
They both look like SOA vs Microservices architectures.
In SOA(Orchastrator) would have ESB(mulesoft/tibco/neuron) which would abstract the target services so you will get loosely coupled endpoints & addition of end points are also easier.
In Microservices (Choreography) you have queue/topic which will be subscribed interested parties which is very much loosely coupled i get this idea.
But it confuses me with SOA paradigm where u r also getting same benifits. So what's the point?, if scaling is problem you have your taget services already independent can be scaled.
Or Am i mixing stuff , can anyone enlighten me.