Understanding RabbitMQ
Let’s take example of movie ticket booking system where there are two services involved. One creates booking and other sends booking details to users.
Once a booking gets created booking service makes a rest call to notification service using which notification service sends notifications to user, and if for some reason notification service is down it retries for the same until notification service responds with the proper status.
If there are lot of booking at the same time it can be time consuming and can slow down the system.
As in this service booking a ticket is more important then sending notification. Even if the notification fails the flow should not break.
The main problem here is that the services are coupled and are dependent on each other directly, which can leads to performance issues and unnecessary complications.
Including the message broker in between can solve the problem. How?
Instead of REST api call now booking service will publish a message to message broker and notification service can consume the message to notify the customer at it’s own time and speed, doing this will decouple the service and now they are not directly dependent on each other.
There are many advantages of this approach
- Booking service is now decoupled with notification service
- Notification service can send messages at it’s own speed.
- If notification service is down it can consume the notification message when it’s up as message broker will store the message until they get consumed
- Even if there are lot of booking at same time consumption can be done in parallel and will not affect booking
- It can also help in scalability as we can deploy many notification service to listen to the same queue in case of lot of bookings
- Queue service can be deployed on a different machine and it can reduce some of the work done by booking service rest api hence reducing the workload for booking service.
RabbitMQ
RabbitMQ is an implementation of AMQP (Advanced Message Queuing Protocol)
The Advanced Message Queuing Protocol is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing, reliability and security.
In our example, the booking service instead of sending messages directly to queues it publishes the message to an exchange.
Exchange is like post office, it delivers the messages based on the address provided to it.
There are mainly 5 different types of exchanges
- Fanout Exchange : In this type of exchange message gets duplicated and will get sent to every queue the exchange knows.
2. Direct Exchange : In direct exchange the message is assigned a routing key and this routing key gets compared with the binding key and if that’s an exact match the message gets delivered to the respective queue.
3. Topic Exchange : Topic exchange forwards the message based on partial matching. For example if the routing ket is “notification.booking” and binding is “notification.any” it will forward the message to that queue.
4. Header Exchange : In this type of change instead of routing keys headers are used to forward the message.
5. Default Exchange : This exchange is very specific to RabbitMQ, it’s not part of AMQP message model. In this type of exchange if the routing key matches to the queue name it forwards the message to that queue. For example routing key “queue-1” and queue name “queue-1”.
In RabbitMQ the messages are being moved based on the message meta-data. This gives flexibility to developers to navigate the message wherever they want instead of giving the control to message broker.
Below is how the message broker looks like in the system for the example given above of movie ticket booking system.
Benefits of RabbitMQ
- Reliability : RabbitMQ offers a variety of features to let you trade off performance with reliability, including persistence, delivery acknowledgements, publisher confirms, and high availability.
- Flexible routing : Messages are routed through exchanges before arriving at queues. RabbitMQ features several built-in exchange types for typical routing logic.
- Cloud Friendly : Easy to start with, you can deploy it with docker or any other containerisation software.
- Cross-Language communication : That means producers and consumers can be written in different languages.
- Acknowledgements : It supports acknowledgements, that means consumers can tell if they have received the message and then only the messages gets removes from queue, that reduces the chance of messages getting lost.
- Management : It provides a good UI to manage the queue, from where you can create or delete queues/exchanges, can add bindings etc.
- More …
To take aways few point, we can sum up that there’s endless ways we can use it. It has flexible message exchange policies and they are highly cloud friendly. There’s lot of developer support available to it. It also has lot of plugin support in many different languages. Big community and good documentation makes it easy to access and debug which can make the learning curve easy.
