More than 63%+ of organizations said in a Dzone survey that they are adopting Microservices for some or all of their applications.
As more businesses adopt the use of Microservice architectures, we as developers have to become more skilled with Microservices communication.
Working with distributed systems is both fun and challenging at the same time. One of those challenges is designing effective communication between services.
More centralization or less centralization? More coupling or less coupling? More control or less control?
These are only a few questions you need to answer.
In this week's newsletter, we will:
Break down Orchestration vs. Choreography
Understand key differences and tradeoffs between them
Create a framework for deciding which approach to use
Let's dive in!
What Are Microservices?
Microservices are a software architecture style where an application is built from small, autonomous services. Each microservice serves a distinct purpose and can be independently deployed.
You probably already know this, so this is a quick refresher.
Here are the key tenets of Microservices:
A significant challenge is designing effective inter-service communication within this distributed environment.
Inside a Monolith system, communication happens through direct method calls. This is a straightforward approach that works well when all components live within a single process. However, this doesn't work with microservices.
Orchestration - Command-driven Communication
Orchestration is a centralized approach to Microservices communication. One of the services takes on the role of the orchestrator and coordinates the communication between services.
Orchestration uses command-driven communication. The command communicates the intent of the action. The sender wants something to happen, and the recipient doesn't need to know who sent the command.
An example of orchestration can be a Saga implemented with RabbitMQ.
It has some nice benefits:
Ease of troubleshooting
Monitoring is straightforward
Orchestration is typically simpler to implement and maintain than choreography. Because there is a central coordinator, you can manage and monitor service interactions. This, in turn, improves troubleshooting, as you know where to look when something goes wrong.
The drawbacks of orchestration are:
Single point of failure
Difficulty adding, removing, or replacing microservices
Choreography - Event-driven Communication
Choreography is a decentralized communication approach. Choreography uses event-driven communication - as opposed to orchestration, which uses commands.
An event is something that has happened in the past and is a fact. The sender does not know who will handle the event or what will happen after processing it.
I talked about events in-depth in the newsletter about publishing domain events.
The most important benefits of choreography are:
Ease of maintenance
Choreography allows microservices to be loosely coupled, which means they can operate independently and asynchronously. This makes the system more scalable and resilient. A failure of one microservice won't necessarily affect microservices.
Of course, there are downsides to choreography:
Monitoring is difficult
It's more complex to implement and maintain than orchestration.
Effective monitoring is the biggest challenge from my experience.
The Crossroads: Which One Should You Choose?
So, how do you know which one to pick for your system?
I always start with the requirements of the system I'm building. And then, I look at the pros and cons of orchestration vs. choreography. Here's a small framework to help you decide.
Orchestration excels when:
You need to wait for the completion of intermediate steps (such as credit card payment confirmation)
You need to make a conditional choice of subsequent steps
The process must be carried out atomically (entirely or not at all)
The process needs to be centralized in one place for monitoring
This also means you will need a central database managed by the orchestrator to handle all workflow-related state.
Choreography works best when:
The process can rely on the input message without needing additional context
Steps clearly follow one another
Progress is made in one direction
You can benefit from increased flexibility (such as modifying individual steps in isolation). Unfortunately, choreography can make it difficult to trace, debug, or monitor the processes triggered by an event. And the larger the event stream is, the more challenging it becomes.
So, think carefully before opting for orchestration or choreography.
Both approaches bring their advantages but also downsides.
Orchestration defines a sequence of steps that each microservice must follow. This is great for identifying and addressing complex service interdependencies. Another benefit is that business logic can be managed and monitored in one place.
Choreography, on the other hand, is a decentralized technique for microservices communication. Each service can operate independently while still being part of the larger architecture.
To decide which approach to use, you should observe your system and identify what you stand to gain or lose. Everything is a tradeoff.
There's also an alternative approach I want to mention.
You could go for a hybrid approach that integrates orchestration and choreography.
In a hybrid approach, you decide which communication technique to use for a specific workflow. Some workflows can benefit from orchestration, and others can benefit more from choreography.
Hope this was helpful.
I'll see you next week!
P.S. Whenever you’re ready, there are 2 ways I can help you:
Pragmatic Clean Architecture: This comprehensive course will teach you the system I use to ship production-ready applications using Clean Architecture. Learn how to apply the best practices of modern software architecture. Join 950+ students here.