Message Broker In Microservices

Each Service handles and collaborates with other services in order to perform on a given request coming from the Client via inter-communication among them.

Communication may take place by 2 broad categories:

1. Synchronous
2. Asynchronous

What to expect from this reading at the end❓

• Understanding the concept of Message Broker with a real-time example
• How inter-communication take place in a microservice architecture❓
• Traditional Messaging Models
• Types of Message Broker and how to choose one of them❓

(Note: This article is for clarifying the basics of Messaging so that we can go deeper and see how to use messaging in our own code)

Concept of Message Broker:

Let’s go with the literal name “Message Broker” to understand it. Broker means a third party/middleMan that helps to perform or achieve our goal. In this case, its service as we are talking about microservices.

So, Broker which helps services to do inter-communication via messaging is Message Broker.

e.g.

Case 1. An Owner is searching for a tenant to rent out his apartment. So, to make his life easy he hired a broker who will help him in getting a tenant.

Apartment searching case

Case 2. Service A (Provider)wants to communicate with service B(Consumer). But Service A doesn’t know anything about Service B, here you might be thinking 🤔 why doesn’t he use Service Registry for knowing the location of Service B and then communicate. Fine, if you are thinking so then you are right but actually it’s not a good idea as this approach will create chaos and affect the performance.

Ohh no 🤯, how to make life easy❓🧐 let me hire a message broker how will do this for me. 😊

Inter-communication via messaging

Co-relate above both cases, hoping you understood the idea clearly.

How do services in a microservice architecture communicate❓

Services use Asynchronous way for inter-communication by exchanging messages over messaging channels/message broker and to do this there are lots of Styles as follow:

• Notifications — a sender sends a message to a recipient but does not expect any/nor even get any reply. 😉
• Request/response — a service sends a request message to a recipient and expects to receive a reply of the message promptly.
• Request/asynchronous response — a service sends a request message to a recipient and expects to receive a reply of the message eventually.
• Publish/subscribe — a service publishes a message to zero or more recipients
• Publish/asynchronous response — a service publishes a request to one or recipients, some of whom send back a reply but some don’t.

Traditional Messaging Models :

1. Queuing: In a queue, a pool of consumers may read from a server and each record goes to one of them meaning, imagine it like a basket full of apples from which each kid has to grab. So, if it grabbed by one kid then the other will not get the same. The main advantage of queuing is that it allows you to divide up the processing of data over multiple consumer instances, which lets you scale your processing.
2. Publish-subscribe: In publish-subscribe, the record gets broadcast to all consumers, but has no way of scaling processing since every message goes to every subscriber.

Available Message-Brokers :

There are numerous asynchronous messaging techniques such as :

• RabbitMQ
• Kafka

Note:- Redis can be included for logical understanding but remember it is for short in-memory messages and that the reason, its mainly used while caching .

Which Microservice Message Broker to choose❓🤔

RabbitMQ (AMQP):

Queuing (One-to-one ) And Publish-subscribe(one-to-many): Both.

Scale: Can send thousands of messages/second.

Persistency: both persistent and transient messages are supported.

It’s an open-source that delivers messages through both point-to-point and pub-sub methods by implementing Advanced Message Queuing Protocols (AMQP). It’s designed to support complex routing logic.

Kafka:

Queuing (One-to-one ) And Publish-subscribe(one-to-many): One-to-many.

Scale: Can send millions of messages/second.

Persistency: yes

Any message queue that allows publishing messages decoupled from consuming them is effectively acting as a storage system for the in-flight messages. What is different about Kafka is that it is a very good storage system. It provides data persistency and stores streams of records that render it capable of exchanging quality messages.

I hope, everything is clear till now and now we gonna see RabbitMQ in detail with Spring Cloud in the next article.