How Microservices Communicate with each other

Microservices are a great framework for any enterprise, but it is of no use if they cannot communicate with each other smoothly.

A microservices-based application is a distributed system running on multiple processes or services, usually even across multiple servers or hosts. Each service instance is typically a process. Therefore, services must interact using an interprocess communication protocol such as HTTP, AMQP, or a binary protocol like TCP, depending on the nature of each service.

When we are talking about Monolithic applications, we said that communication in Monolithic applications is interprocess communication. So that means it is working on a single process that invokes one to another by using method calls. You just create a class and call the method inside of the target module. All running the same process.

One of the biggest challenges when moving to microservices-based applications is changing the communication mechanism. Because microservices are distributed and microservices communicate with each other by interservice communication on the network level.

Each microservice has its instance and process. Therefore, services must interact using an inter-service communication protocol like HTTP, gRPC, or message brokers AMQP protocol.

Microservices Communication Types — Synchronous communication or Async Communication

Synchronous protocol: The synchronous communication protocols can be HTTP or HTTPS. In synchronous communication, the client sends a request with using HTTP protocols and waits for a response from the service.

So that means the client calls the server and blocks the client their operations. The client side code will continue its task when it receives the HTTP server response. So this operation is called Synchronous communication.

It has pros and cons that we should consider when we pick this way.

Asynchronous protocol: In Asynchronous communication, the client sends a request but it doesn’t wait for a response from the service. So the key point here is that the client should not have blocked a thread while waiting for a response.

The most popular protocol for this Asynchronous communication is AMQP (Advanced Message Queuing Protocol). So by using AMQP protocols, the client sends the message with using message broker systems like Kafka and RabbitMQ queue.

Another point that we need to consider is if the communication has a single receiver or multiple receivers.

Single receiver: Each request must be processed by exactly one receiver or service. An example of this communication is the Command pattern.

Multiple receivers: Each request can be processed by zero to multiple receivers. This type of communication must be asynchronous. An example is the publish/subscribe mechanism used in patterns like Event-driven architecture.

Microservices Communication Styles:

There are many protocols and choices you can use for communication, depending on the communication type you want to use.
If you’re communicating between services internally (within your Docker host or microservices cluster), you might also want to use binary format communication mechanisms like WCF using TCP and binary format.

There are also multiple message formats like JSON or XML, or even binary formats, which can be more efficient.
We can use message-based communication mechanisms such as AMQP.

SignalR is a good way to achieve real-time communication for pushing content to the clients from a back-end server. Since communication is in real-time, client apps show the changes almost instantly. This is usually handled by a protocol such as WebSockets, using many WebSockets connections (one per client).

Points to Remember:

• Try to avoid multiple synchronous dependencies between microservices, such as query requests, the worse the overall response time gets for the client apps.
• Orchestration of your microservices is a key factor of success in both process and tooling.
• Use asynchronous communication to achieve loose coupling.
• Ensure your API changes are backward compatible.
• Fail fast by using a circuit breaker to achieve fault tolerance.
• Identity the right Messaging pattern for your microservices.

References: https://docs.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr

Conclusion

There are many communication patterns for microservices out there that are doable in a microservice-based architecture. It can be achieved in both synchronous and asynchronous patterns.

Implementation of the microservice looks easy at the onset. The size and focus of these smaller elements simplify the tasks and are much better than the archetypal monolith architecture. But in the case of multiple services that are interdependent, things can get quite challenging. The distributed nature of the system can lead to technical glitches. It will be better to deploy them as independent entities.