As you remember from my last article, I have been discussing two types of microservice communication mechanisms.

1. Synchronous communication.
2. Asynchronous communication.

We have covered some basic stuff about synchronous communication (what is synchronous communication, best practices, different types of synchronous method so on...). If you didn't read the article I suggest to head over that before reading this by clicking here.

So in this article, we will be focusing more on asynchronous communication, the second type of communication mechanism. Let's start with problems of synchronous communication.

Problems with Synchronous communication.

• When we do HTTP calls between multiple services (chain query),

  • Increase latency with high coupling services.
  • Performance, scalability and availability problems.

• To avoid these problems,

  • Reduce the interservice communication.
  • Make microservice communication asynchronous.

Asynchronous communication.

• In asynchronous communication, client sends the request and it does not wait for the servers response.
• The message brokers handle the message in asynchronous manner.
• The message brokers store the message until consumer consume it.
• If the consumer service is dead, brokers are configured to retry until the successful delivery.
• Messages in the brokers can be persist if it is required, or it could share in memory.

• There is one term you should know when we talk about the message brokers. It is "Events".
• Any action or occurrence in a system, that needs to communicate with the other parts of the system know as an "Event".

Benefits Asynchronous communication.

• Allows to add and remove subscribers without affecting to producer service.
• Can scale producers, brokers and subscribers independently.
• Event driven architecture is the best way to communicate between microservices by creating and sending events to brokers and subscribing event from brokers.
• If the broker is down when send the message, it can retry for successful delivery.

Types of asynchronous messaging communications.

1. One-to-one(queue) - single receiver - point to point model

• If you send 1 request to a specific consumer and the operation will take a long time, it is better to use one-to-one(queue) asynchronous communication.
• One producer and one consumer. Implement as a command pattern.

Ex:- RabbitMQ, ActiveMQ, Amazon SQS

2. One-to-many(topic) - multi receivers - publish/subscribe model

• Producers publish an event and it consumes from zero to multiple microservices by subscribing events on the broker system.
• Publishers don’t need to know any subscribers.
• Events(messages) are available to all subscribers and topics can have more than one subscriber.
• The messages remain persistent in a topic until they are deleted.

Ex:- Kafka, RabbitMQ, Amazon SNS and EventBridge.

Note : If a client waits for the response, we use Synchronous communication. If the client does not wait for the communication, then we use Asynchronous communication.

Fan-Out Pattern.

• This refers the brokers efficiently send messages to all the subscribers.
• Message Fanned out parallelly to multiple destinations.
• In publisher subscriber model, publisher sends the message to the topic, message is immediately fanned out to all subscribers of this topic.
• Each service can operate and scale independently and individually that is completely decoupled and asynchronously. - All components that subscribe to the topic receive every message unless a message filtering policy is set by the subscriber.

Topic-Queue Chaining and Load Balancing Pattern.

• Mostly related to resilience in microservices and mostly used on serverless architecture.
• Publishers publish the message with fire-and-forget. So it will lose when a microservice is down.
• In the Topic-Queue pattern, we add a queue between the event bus(topic) and each of the subscribers. The queue can act as a buffering load balancer.

Note:- with using Kafka, you don't need to use an additional queue mechanism. Because, Kafka can already persist messages into clusters. When the subscribers are up and running they can consume messages that they subscribed.

Through this article, I have discussed about some of the theoretical concepts of asynchronous communication. We will discuss how to build an application with asynchronous communication (like Kafka) with our future articles. So make sure to follows, if you don't need to miss any of article. Lets meet again with another article.