Wes Bos asked a question on twitter that threw me off a bit.
@derickbailey I’ve never understood what rabbitmq is / what it’s for. Do you have a post or something that explains what I would use it for?
— Wes Bos (@wesbos)
It was a simple question, but I realized that it was one I have never really answered in a blog post or any other material.
So, what is RabbitMQ?
It’s a message broker that makes distributed systems development easy.
But that’s a terrible answer – it doesn’t really tell you what it does or why you should care about it.
This answer also brings up more questions for anyone that isn’t already familiar with messaging systems. And if you’re already familiar with the concepts, then you probably know what RabbitMQ is and does.
To understand RabbitMQ, look at jQuery AJAX calls.
Takes this code as an example:
This is a pretty standard looking AJAX call made with jQuery.
It’s also a perfect example of how you’re already using most of the concepts that RabbitMQ encapsulates.
An AJAX call is distributed computing with messages.
You have a web browser on someone’s computer, and a web server sitting somewhere on the internet.
When the browser makes the AJAX call through jQuery, it takes the “data” parameter and passes it to the web server.
The server looks the URL that was requested, the data provided and does some work based on all of that.
The server will send some kind of response back to the browser – whether it is an immediate response saying that the work was done, or just a “200 ok” saying the message was received, or whatever else.
Additional work may be done on the web server, without the browser knowing about it.
This is distributed computing.
You’re moving some of the work from one system (the computer with the browser) to another (the web server).
Think of RabbitMQ as the back-end AJAX.
If an AJAX call is distributed computing for web browsers, then RabbitMQ is distributed computing for servers.
Instead of dealing with HTTP requests that may be exposed to the internet, RabbitMQ is more often used for back-end services.
There are some key differences, of course. But this is less an analogy than it is a direct parallel – a different implementation of the same basic idea.
Some of these parallels and differences include the following:
|jQuery.ajax||RMQ message “producer” (SDK / API)|
|HTML form encoded data||JSON documents|
|Web Server||RMQ Server / Message Broker|
|API Endpoint / URL||Exchange, Routing Key, Queue|
|Route / request handler
(e.g. MVC controller / action)
|RMQ message “consumer” (SDK / API)|
There’s more subtlety and stark contrast in this comparison then I am explaining in this simple table, but this should give you an idea of how to start thinking about RabbitMQ.
There’s also a lot of new terminology to learn with RabbitMQ (and distributed systems), as with any tech that is new to you. But most of these terms and specifics don’t matter right now.
The one thing that does matter, though, is the message broker.
An AJAX call is a “brokerless” model.
The browser makes the AJAX request directly to the web server that will handle the request. To do this, the browser must know about the server.
In the world of messaging, this is called a brokerless model. There is no broker in between the system requesting the work, and the system doing the work.
RabbitMQ is a “brokered” model.
The RabbitMQ server itself, sits in between the code that makes a request and the code that handles the request.
Because of this, the code that produces messages does not know anything about the code that consumes message.
This third party – the RabbitMQ server – sits in between the message producer and consumer. This allows a complete decoupling of the two services.
While this does add some complexity, it also provides a lot of opportunity for improving system architecture, increasing robustness, allowing multiple systems, languages and platforms to work together and more.
So… What does RabbitMQ do?
RabbitMQ allows software services to communicate across logical and physical distance, using JSON documents.
But that’s still a dry, boring answer.
RabbitMQ allows you to solve a new class of problems in today’s “web scale” world.
- Push work into background processes, freeing your web server up to handle more users
- Scale the most frequently used parts of your system, without having to scale everything
- Handle what would have been catastrophic crashes, with relative ease
- Deal with seemingly impossible response time requirements for webhooks
- Allow services to be written in different languages, on different platforms
- … and so much more
No, RabbitMQ does not do these things directly.
The benefits that you get from RabbitMQ are really the benefits of distributed computing and messaging.
RabbitMQ happens to be a good choice for implementing these types of features and requirements, giving you all the benefits of a message based architecture.
Its’ certainly not the only choice, but it’s the one I’ve generally used for the last 5 years and my software and architecture are better because of it.