Message queues are a fairly old mechanism for establishing communication between a lot of different components inside an application. This old method is even good for our current use cases of the microservices architecture. But before we take a dive into how we can use message queues for making microservice communication asynchronous, let's first take a look at some of the jargon that is used when dealing with this method of communication:

• Message: A message is a kind of package that a particular service generates to communicate about what it wants to achieve to another service.
• Queue: A queue is a kind of topic under which a particular message may come. For any practical application there could be a number of queues, each representing a specific topic of communication.
• Producer: A producer is a service that generates a message and sends it to a specific topic.
• Consumer: A consumer is a service that listens to a specific topic and processes any messages that may come to it.
• Router: A router is a component inside the message queues that is responsible for routing the messages for a particular topic to the appropriate queue.

Now that we know the jargon, we can move on to look at how message queues can help us in establishing communication between the microservices.

When the microservices utilize something like a message queue, they interact over asynchronous protocols. For example, AMQP is one of the more famous protocols for asynchronous communication.

With asynchronous communication, the communication between microservices will take place as follows:

1. A message broker is set up, which will provide the functionality for the management of the message queues and the routing of the messages to the appropriate queue.
2. A new service comes up and registers the topic it wants to listen to or send the messages to. The message broker creates an appropriate queue for the topic and adds the requesting service as either a consumer or a producer for that queue. This process also continues for other services.
3. Now, a service that wants to achieve a particular goal sends a message to the topic, let's say Topic Authenticate.

4. A consumer listening to Topic Authenticate is notified about a new message and consumes it.
5. The consumer processes the message it has consumed and puts a response back on another topic, Topic Auth_Response.
6. The producer of the original message is the consumer for Topic Auth_Response, and is notified about a new message.
7. The original requesting client then reads this message and completes the request–response cycle.

Now, we know what communication inside a microservices architecture that is powered by asynchronous message queues looks like. But is there any other benefit to this method other than asynchronous communication?

It turns out that there are a number of benefits that we may see from such a communication pattern. The following list shows some of the benefits that we may experience:

• Better distribution of requests: Since there could be a number of consumers that may be listening to a particular topic, the messages can be processed in parallel, and load balancing can be automatically taken care of by the equal distribution of messages among the consumers.
• Better error resilience: In the case where a particular microservice goes down, the messages that need to be processed by that microservice can be queued up inside the message queue for a certain time, and can then be processed by the service once it comes up, reducing possible data loss.
• Reduction in duplicate responses: Since a message is delivered only once to a single consumer and is dequeued as soon as it is consumed, there is a very small chance that there could be duplicate responses for a single request.
• Increased tolerance: During a time when the different microservices inside an infrastructure are experiencing high loads, the message queue system provides an asynchronous request–response cycle, thereby reducing the chance of request queue-ups.

With this, we now have an idea of how we can establish asynchronous communication between the microservices and make our infrastructure evolve over time without having to worry about how to handle the addition of new API endpoints for interservice communication.