Microservices Communication Types

Microservices communicate with each other in two common ways: Synchronous and Asynchronous.

Synchronous communication

The caller microservice waits for a response before sending the next message. The other microservice will send back to caller when receive the request or process the request (it depends on the business). Something like REST call. You make a REST call then wait for response.

Asynchronous communication

This communication is based on sending messages. messages are sent without waiting for a response. This communication is good for distributed systems and usually requires a message broker (like: RabbitMq, Redis, Kafka, ..) to manage the messages.

Each microservices communicate ways contains some types. Which are as following

Synchronous communication ways:

Remote Procedure Call (RPC)

Direct way. this way is good when a request needs an immediate response. For example, a microservice has a financial algorithm and responds with data based on the values passed into the request. The client (monolith client or another microservice) supplies the parameter values, sends the request, and waits for the response. The business process does not continue until it has received an answer or an error. Using RPC should be limited in use. It has a high potential of adding unnecessary latency (due to limited band width and speed of internet) for the client and should only be used when the processing inside the microservice is small and also response is not that much huge

Asynchronous communication ways:

Fire-and-Forget

The client does not care if the microservice can complete the request, just ask to do something but no wait for response. An example of this style is logging. A business process may need specific information to be logged, but the need to continue processing.

Callback

In this way microservice calls back to the client, notifying when it is done processing. This type is desponds on something that is called “correlation ID”. correlation ID is like a key which client and microservice both set and get data by it. The business process continues after sending the request. The request contains information for how the microservice is to send the response. This requires the client to open ports to receive the calls and passing the address and port number in the request. With many calls occurring, there is a need to match the response to the request. When passing a correlation ID in the request message and the microservice persisting that information to the response, the client can use the response for further processing.

Publish/Subscribe (Pub/Sub)

This is a way of listening on a message bus for messages. The sender publishes a message for all the listeners to react on their own based on the message.

A persistent-based Pub/Sub model is where only one instance of a listener works on the message. Building on the “fire-and-forget” model mentioned earlier is the logging example. As an event that requires logging occurs, a message is created containing content to be written. Without persistence, each subscriber would log the message and cause duplicate records. Using the persistence model, one subscriber locks the message for processing. Other listeners may pick up the next message, but only one message is processed. Now, only one log entry is created for each event. If the subscriber fails to complete their task, then the message is aborted, and another subscriber can pick it up

for processing. This way needs some important consideration:

1- what happen if publisher published a message but subscriber is down?

2- what happen if publisher published a message but message broker is down?

3- what happen if publisher published a message multiple time?

4- based on number 3 what subscriber must do. How prevent processing same messages?

We can continue in more questions and considerations. These questions and considerations must be solved and have solution.

Solution is in Acknowledgment for messages, persist Queues, outbox or inbox pattern, idempotency and some more.

Notice:

When choosing a message broker for executing your asynchronous operations, you should consider a few things:

1. Broker Scale — The number of messages sent per second in the system.
2. Data Persistency — The ability to recover messages.
3. Consumer Capability — Whether the broker is capable of managing one-to-one and/or one-to-many consumers.

Reference and more detail

https://www.amazon.com/Pro-Microservices-NET-MassTransit-Kubernetes/dp/1484278321