Getting started with Message Brokers using RabbitMQ
This article introduces the need for Message brokers in your application architecture, mainly focussed on RabbitMQ

Before getting started with any technology/tool, you should first ask Why is this required? Because when you introduce new tech/tool in your application, it takes a lot of effort from learning to implementation. So, let's get started with why Message brokers exist in the first place.
Consider the below use cases:
-
You have a web service that receives so many requests per second and you can't afford to lose any of them. Also, all of these requests need to be processed by a system that is time-consuming.
-
You have an advanced microservice architecture built using different platforms among which data needs to be shared where this data is not being stored in any database.
In these 2 scenarios, you need a temporary system that can store/hold the data and should be able to transfer to multiple systems whenever they are ready to take the input. Message Brokers serve the exact same purpose.
RabbitMQ is one of the leading and popular message brokers used by many tech giants. So, the RabbitMQ server uses AMQP to accept and forward messages.
-
AMQP – Advanced message queueing protocol, used for communicating between applications of different platforms.
The above image shows how a Message broker works in a simple way. Now let's get to know about each component in the image
- Publisher: The systems which generate data are publishers. They'll send the data to RabbitMQ Exchanges.
- Exchange: They are AMQP entities where messages are sent. Exchanges take a message and route it into zero or more queues. The routing algorithm used depends on the exchange type and rules called bindings. The exchange type defines how data is delivered to queues.
- Queue: This is the actual place where data is stored in the entire RabbitMQ workflow. A queue is only bound by the host's memory & disk limits.
Queues share some properties with exchanges to enable binding between the two. - Consumers: Applications must subscribe to queues in order to receive messages immediately when the queue receives it from publishers.
It is possible to have more than one consumer per queue or to register an exclusive consumer.
Use-Case: Consider you are developing an E-commerce application. On the day of a special sale, you'll receive a lot many orders. But you don't have the required infrastructure or scalability to handle them. This makes your servers slow leading to a crash.
To avoid this, you can add a message broker in the middle, pass order details to RabbitMQ so that your application will be ready to take new orders. You can process the previous order once your system is ready by passing the data to the consumer when asked.
System requirements for RabbitMQ:
- Rabbitmq is by default allowed to use 40% of the total system RAM, which can be tweaked to 50% on 1GB RAM machine.
- It requires a minimum of 200MB free disk space.
Thanks for your time, keep watching this space as we'll be publishing articles with RabbitMQ implementation along with code. Keep rocking!!