Do people still use RabbitMQ?
Yes. RabbitMQ is actively developed, shipped under the Mozilla Public License 2.0, and maintained by Broadcom with a public repository and regular releases. Version 4.0 removed classic mirrored queues and made quorum queues the recommended replicated queue type. It remains the default broker behind Celery, Spring AMQP, and OpenStack's internal messaging.
Why the question gets asked
Two things make RabbitMQ look quieter than it is. The first is Kafka. Since roughly 2015 the conversation about moving data between services has been dominated by the log, and a great deal of writing about Kafka opens by describing what queues cannot do. That framing turns a difference in shape into a difference in age, and RabbitMQ ends up sounding like the thing Kafka replaced rather than the thing that solves a different problem. Kafka vs RabbitMQ works through where the split actually falls.
The second is a real deprecation that people half-remember. Classic mirrored queues, the original way to replicate a queue across a RabbitMQ cluster, were deprecated and then removed. Searching for them turns up removal notices, upgrade warnings, and migration guides, and it is easy to read that as the project winding down. It was one feature being retired in favor of a better one, in the same way NATS Streaming gave way to JetStream without NATS going anywhere. Is NATS deprecated? covers that parallel case.
Ownership changes did not help either. RabbitMQ came from Rabbit Technologies, went to VMware by way of Pivotal, and arrived at Broadcom when Broadcom acquired VMware. Each transfer produced a round of speculation about the open source edition. The server is still MPL 2.0, still on GitHub, and still releasing.
What RabbitMQ 4.0 changed
Quorum queues are now the answer for replicated queues. They use Raft for consensus instead of the leader-and-mirrors arrangement classic mirrored queues used, which means they have predictable behavior during network partitions and no split-brain recovery mode that quietly drops messages. If you learned RabbitMQ before this change, the mental model worth updating is that replication is a property of a quorum queue rather than a policy you apply to a normal one.
AMQP 1.0 became a native protocol in the server rather than a plugin, so RabbitMQ now speaks the ISO-standard version of AMQP as a first-class citizen alongside the 0-9-1 dialect most clients use. Khepri, a Raft-based metadata store, has been replacing Mnesia for cluster state, which removes the oldest source of cluster recovery pain.
Streams, added earlier in the 3.x line, are worth knowing about separately. A stream is an append-only log with retention and replay, sitting inside the same broker as your queues and reachable from the same connection. It covers the fan-out-and-replay cases that used to force teams to run Kafka alongside RabbitMQ.
The jobs RabbitMQ still wins
Work distribution is the obvious one. When several workers pull from a queue, each message goes to exactly one of them, and a worker that dies has its unacknowledged messages redelivered. Kafka's partition model gives you ordering per partition and caps consumer parallelism at the partition count, which is the wrong shape for a pool of workers doing variable-length jobs. This is why Celery, Sidekiq's AMQP setups, and most background job systems still point at RabbitMQ.
Routing is the other. Exchanges, bindings, and routing keys let the broker decide where a message goes based on rules you declare once, rather than every consumer filtering a shared topic. Combine that with per-queue dead letter queues, message TTLs, and priorities, and a lot of logic that would otherwise live in application code becomes broker configuration.
It is also easy to run. A single container gets you a working broker with a management UI, as the RabbitMQ Docker setup guide shows, and Amazon MQ and CloudAMQP will operate it for you if you would rather not.
When to reach for something else
Pick Kafka when you need a long retention window you can replay repeatedly, throughput measured in millions of messages per second, or a connector ecosystem. Pick NATS when operational simplicity and low latency matter more than broker-side routing features. Pick Redis when the queue is small, the work is short, and you already run Redis for other reasons.
And one boundary is worth stating plainly, because it catches teams late: an internal broker is not a delivery mechanism for your customers. RabbitMQ moves messages between systems you control, where you own both ends and can fix a consumer that misbehaves. Sending webhooks to endpoints your customers own is a different problem, with signature verification, per-endpoint retry schedules, and delivery logs your customers can read for themselves. Svix provides that layer, and it sits downstream of whichever message broker you pick rather than replacing it.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis