Message broker – Async communication between services

In the previous topic, we talked about synchronous communication between microservices using binary and alternatives to REST. This topic will deal with the communication between microservices using message broker, that is, a messaging system with a physical element, a communication layer, and a message bus.

With messaging systems, it is impossible to reproduce the Death Star. The design of the Death Star in a more robust application would be something like the following:

The diagram of a messaging system is totally different, similar to the one shown in the following:

The message bus can be used for both synchronous and asynchronous communication, but certainly, the major point of emphasis of the message bus is in asynchronous communication.

You may wonder, if the messaging diagram is simpler and you can use this type of tool for synchronous communication, why not use this messaging for all types of communication between microservices?

The answer to this question is quite simple. A message bus is a physical component within the stack of microservices. It needs to be scaled just like any other physical component-based data storage and cache. This means that with a high-volume message, the synchronous mode of communication could be committed to an unwanted delay in the responses of the processes.

It is critical to the engineering team to understand where to correctly apply each tool without compromising the stack because of an apparent ease.

Within the various message brokers, there are some that stand out more, such as:

• ActiveMQ
• RabbitMQ
• Kafka

Let us understand the functioning of each of them a little better.