Messaging and message bus

This mode of communication is used when services have to handle the requests from various client interfaces. Services need to collaborate with each other to handle some specific operations, for which they need to use an inter-process communication protocol. Asynchronous messaging and message bus is one of them. Microservices communicate with each other by exchanging messages over various messaging channels. Apache Kafka, RabbitMQ, and ActiveMQ, Kestrel are some of the widely available message brokers that can be used for communication between microservices.

The message broker ultimately does the following set of functionalities:

• Route messages coming from various clients to different microservices destinations.
• Changes messages to desired transformations as per need.
• Ability to do message aggregations, segregate a message into multiple messages, and send them to the destination as per need and recompose them.
• Respond to errors or events.
• Provide content and routing using the publish-subscribe pattern.
• Using message bus as a means of communication between microservices has the following advantages:
• The client is decoupled from the services; they don't need to discover any services. Loosely coupled architecture throughout.
• Highly available as the message broker persists messages until the consumer is able to process them for operations.
• It has support for a variety of communication patterns, including the widely used request/reply, notifications, async responses, publish-subscribe, and so on.

While this mode provides several advantages, it increases the complexity of adding a message broker that should be made highly available, as it can become a single point of failure. It also implies the need for the client to discover the location of the message broker, the single point of contact.