What is RabbitMQ?

Every kind of communication needs a speaker, a message, and a listener. When you’re on the internet, watching a lecture, a movie, reading a book, or even talking with friends at a bar, you’re in a communication system. Inside an application it’s not different.

When we have a system divided in different modules (microservices), we need to ensure that communication will flow between them, right? For that, there is a bunch of message tools, and RabbitMQ is one of them.

Inside this process we call the speaker “publisher” and the listener “consumer”. Like every scenario from real world, messages needs to be clear, therefore we create queues to translate that communication. Each of them has different criterions and before everything, the message goes to the exchange, to be a “route controller”.

Let’s clarify some concepts before talk more about exchanges. The binding key is a specific key that “opens doors” to specific queues, creating the bond between exchange and queues. The messages also needs to be interpreted to get into the routes, so we have the routing keys. It’s a key that exchange uses, so messages can have access to a certain queue and its bindings. Let’s say that you’re having a trip and the road has different lanes for different vehicles, like trucks, cars, and motorcycles that needs to be apart. Your vehicle has a routing key that provides access to the right road for you, while the binding key will be the toll that leads a road to another.

There is some differences between exchanges types that will fulfill the requirements of each architecture and right after binding, sends the message to be consumed by the correct queue.

Direct Exchange: sends the messages that have binding key just like the routing key.

Topic Exchange: the routing key is a list of dotted words that will match with binding key words. So it’s kind of a filter.

Fanout Exchange: sends the message to all queues with binding, no matter the routing key.

Header Exchange: uses the header’s value to send the message, no matter the routing key.

Try to think about a lecture, the communication is completely different than in a bar talk. In a lecture we have a speaker, spreading the same message to several people (1 → N). On the other hand, at the bar, the conversation has only one speaker and listener (1 → 1). In this case, we configure different bindings to “categorize” the type of communication. The exchange understand this relationship and sign the contract according to the binding made in every queue.

One thing can never be lost: the message. It needs to be extremely consistent, whether the publisher or the consumer are down, RabbitMQ ensures that message will be recreated if, for any reason, any part of the application is not healthy. Another advantage is the asynchronicity, once we have created a structure of queues parallelizing user requests we can have a better performance delivering the messages once they’re ready, not having any blocks, giving a faster response to users.

Like everything in life, RabbitMQ also has his trade offs. Its asynchronicity doesn’t allow us to guarantee the queues’ messages processing order. Another important thing to say is that once you consume the message, it will be deleted if you don’t save it in memory, but remember that it has a cost to your server.

It’s always a good reminder that you should understand your needs first to lookup for the right tool.

“There is no silver bullet. There are always options and the options have consequences.”

I’m sure RabbitMQ can easily solve a lot of problems and it’s a really good option for your application if you need a large capacity of processing for a low price. Let me know your thoughts. 🙂