What is RabbitMQ?
RabbitMQ is a message broker. It sits between the parts of a system that produce work and the parts that do it, holds messages until someone is ready, and makes sure each one is handled.
It implements AMQP 0-9-1 along with extensions, supports publish/subscribe, work queues and request/reply, and is licensed under MPL-2.0. It began at Rabbit Technologies and is now maintained under Broadcom.
The problem it solves
Without a broker, one service calls another directly and waits. That works until it does not:
- The second service is down, so the first one fails too, and a user sees an error about something they did not ask for.
- The second service is slow, so the first one blocks, and the slowness spreads through the system.
- Work arrives faster than it can be processed, and there is nowhere to put the excess but memory.
A broker turns the call into a handoff. The producer writes a message and moves on. The consumer takes it when it can. If the consumer is down, the queue holds. If work arrives in a burst, the queue absorbs it. If one consumer is not enough, you add another and they share the queue.
The usual first application is exactly this: an operation that takes seconds and does not need to happen while the user waits. Send the confirmation email, generate the PDF, re-index the record. Push it onto a queue, return the page immediately.
It also gives you something to scale on
This is the part that gets noticed later and is often worth more than the decoupling.
Once work goes through a queue, the producers and the consumers are separate deployments, and they scale independently. A traffic spike adds producers without touching the workers; a backlog adds workers without touching the web tier.
More usefully, the queue hands you an honest signal to scale on. Autoscaling on CPU is a proxy for how busy something is, and a poor one: a worker waiting on a slow external API looks idle while being fully occupied. Queue depth is the actual measure of unfinished work. If it is growing, the current workers cannot keep up, whatever their CPU says. If it is draining, you have more capacity than you need and can give it back.
That makes the scaling rule simple enough to write down and trust: add consumers while the backlog grows, remove them once it clears.
Queues and streams are different things
This is the distinction that decides whether RabbitMQ is your answer, and it is where most confusion sits.
A queue distributes work. Each message goes to one consumer, which acknowledges it, and then it is gone. Add consumers and the work is shared. The queue is a buffer, not a record.
A stream keeps a log. Messages persist after being read, several independent consumers each read the whole thing at their own position, and a new consumer can start from the beginning. The log is the record.
RabbitMQ is built around the first, and has grown features for the second. Kafka is built around the second. If your requirement is that many systems each process every event, and that a consumer added next year can replay last year, you are describing a log and should look at one. If your requirement is getting work off the request path and spreading it across workers, a broker is the smaller, simpler answer.
When you need one
- Slow work on the request path. The clearest case, and the one that pays back immediately.
- Services that must not fail together. A queue is a shock absorber between them.
- Bursty load. Queue depth grows and drains instead of the system falling over, and it is the signal you autoscale the workers on.
- Fan-out. One event, several interested subscribers, without the producer knowing who they are.
When you do not
A single application with fast operations does not need one. A broker is another component to run, monitor and reason about, and adding it before there is a queueing problem buys complexity and no benefit.
When "just use the database" is honest. A small work queue in a PostgreSQL table is a legitimate design at low volume. It stops being legitimate at high volume, but plenty of systems never get there.
When you need the log. See above. Choosing a broker for a streaming requirement means rebuilding a log badly.
What running a cluster involves
- Durability is a choice you make. Messages, queues and exchanges are each durable or not, and publishes can be confirmed or fire-and-forget. Defaults do not know how much your messages matter.
- Queues have to be bounded. An unbounded queue with a stuck consumer grows until it takes down the broker. Length limits and dead-letter queues are how the failure stays local.
- Clustering has real semantics. A cluster is for availability, and what happens during a network partition is a configuration decision with data-loss consequences either way.
- Watch depth and rate together. A queue growing steadily means consumers are behind, and that is visible long before anything breaks, if someone is looking.
- Upgrades are coordinated. Broker and clients have version expectations, and rolling a cluster with active connections needs a plan.
The failure mode is rarely the broker crashing. It is a queue nobody bounded, filling up over a weekend because one consumer died quietly on Friday.
Where VSHN fits
VSHN operates RabbitMQ on Swiss cloud infrastructure with 24/7 operations, on Cloudscale and enterprise private cloud, with AMQP, MQTT and STOMP available and daily backups. Servala offers self-service ordering.
If you are still deciding between a broker and a log, that is worth settling first: it is a harder thing to change later than which provider runs it. Our hosting comparison covers the provider question once you get there.