For the longest time, we were dependent on other conventional queue managers to implement our data exchange between multiple subsystems. Although it served our purpose there was always an efficiency issue when it came down to handling large-scale data exchange with multiple entities. Therefore we were in need of a one-stop solution that could help us interact with all of them, as well as handle and control all the required data exchange from one place.
To describe it in a layman’s language, Imagine it like multiple lines between multiple endpoints but intersecting at the same place like the diagonals of any closed curve.
In our search for that perfect solution, we tried multiple avenues like Bull, Bee-Queue, and Kue But to our disappointment, none of it could help us address our requirements, as all of them worked well in one aspect while failed in another. The issue of data persistence kept bothering us. The search was ongoing when one of our team members read about RabbitMQ. Once we started exploring RabbitMQ, we were sure that our search for a perfect solution to our problem had come to an end.
RabbitMQ quickly became our intersection point from where every bit of data flowed effortlessly from one entity to another. The concept was clean and the features available solved all of our problems with ease. And thus RabbitMQ became our one-stop solution.
The challenges faced!
While Implementing RabbitMQ to our existing large-scale model we came across a number of challenges. Using RabbitMQ meant that we would have to rework our entire data-sharing network within multiple subsystems and have to make sure it did not hamper any of our existing features and functionality. The biggest issue we faced was implementing RabbitMQ as a full-blown queue manager which has to interact with every entity and process messages through multiple queues before reaching the intended destination. All the queues were supposed to work independently but the same data needed to pass through all the entities required before finishing at the required place. The other limitation we faced was the fact that there were only a fixed number of channels that could be created per connection and that meant that we needed to restrict our usage for each connection, which was not an ideal situation for us. After trying multiple tricks and solutions, we finally reached a stable answer which helped us overcome the said issue.
The presence of exchanges gave us a chance to actually implement data exchange between multiple entries as passing messages to various locations became easy.
Another challenge that bothered us was to stop the consumers independently. It means that the data needs to stay idle in the queue until the consumer is restarted. All these challenges were tricky but our team proved more than capable of implementing all the said functionalities and made a perfect RabbitMQ model.
Despite all these challenges, the in-built features available made our system flexible and efficient. The plugins like delayed messages proved to be a vital addition to our existing system and the acknowledgement feature was a bonus that helped us keep track of any data packet or message that could not reach its desired location.
Well since we have been talking about our challenges and how RabbitMQ came to our rescue, let’s talk about what exactly RabbitMQ is!
What is RabbitMQ?
RabbitMQ is a reliable message broker that is used to publish and consume messages between different services with a guarantee that messages will not get lost in transition.
When we talk about a conventional queueing system, messages in a queue can sometimes remain undelivered. Instead of silently dropping, RabbitMQ can be configured to “ dead letter”, that is to republish undelivered messages from a queue to an exchange. But what exactly is an Exchange?
To put it simply, Exchanges are message routing agents, defined by the virtual host within RabbitMQ. An exchange is responsible for routing the message to different queues with the help of header attributes, bindings, and routing keys. Let’s understand it better with an example, when we post a letter to another person, we write down the address on the letter where we want it to be delivered. When it reaches the post office, the people there see the pin code on the letter and send it to its respective PO where with the local address the letter reaches its destination. In terms of exchange, bindings are the pin code and routing keys are the local address that helps the message reach its proper destination.
What’s more about it?
There are 4 key components that one needs to understand while working with RabbitMQ, which include –
The combination of these four is what makes the queue manager known as RabbitMQ.
Apart from these, there are two more features that one should know about namely Publisher and Consumer. As the name suggests, publishers are used for publishing a message into the system and consumers consume them. So in short they are the gates through which a message passes to get from one point to another.
To conclude, implementing RabbitMQ has been a great learning experience and has helped us make our product more flexible and efficient. RabbitMQ has been a safe choice for us to take our product one step higher and fulfill all our requirements in terms of making the product more agile.