What Is RabbitMQ Used For? 9 Common Use Cases

RabbitMQ is an open-source message broker. It is used mainly to queue background work, such as Celery tasks and other jobs that workers pick up, and to decouple microservices so a slow or offline service does not hold up the one sending to it. It also handles request-reply (RPC), publish/subscribe fan-out, routing by topic or headers, IoT messaging over MQTT, replayable streams, and delayed retries through dead lettering. Applications publish messages to an exchange, bindings route them into queues, and consumers acknowledge each message once they have processed it.

Each of those jobs works well up to a point, and each has an operational catch. This post covers both, using current RabbitMQ 4.x behaviour: 4.3 is the current release series, first released on 23 April 2026.

What RabbitMQ is: exchanges, bindings and queues

RabbitMQ speaks several protocols: AMQP 0-9-1, which most client libraries use; AMQP 1.0, a core protocol since 4.0; MQTT 3.1, 3.1.1 and 5.0 through a plugin that ships with the server; STOMP; and a dedicated stream protocol. Whatever the protocol, the model is the same:

Exchanges receive messages and decide where they go. The four standard types are direct (exact routing key), fanout (every bound queue), topic (wildcard patterns) and headers (match on message headers).
Bindings connect exchanges to queues, with a routing key or header rules.
Queues hold messages until a consumer acknowledges them, after which they are deleted. Streams are the exception: an append-only log that consumers read without removing anything.

Routing in the broker, rather than in the clients, is what separates RabbitMQ from a log like Kafka. Our guide to exchanges, queues and bindings covers the topology design in depth.

Common RabbitMQ use cases

Each use case maps to RabbitMQ features, and each has a catch worth knowing before it reaches production:

Use case	What RabbitMQ provides	The catch
Task and job queues (Celery and similar)	A work queue shared by competing consumers, with manual acknowledgements and a prefetch limit per consumer. Celery's documentation names RabbitMQ as its default broker.	Long jobs collide with the consumer timeout, 30 minutes by default; in 4.3 it is enforced by quorum queues and no longer by classic queues. Celery on quorum queues needs global QoS turned off, which disables worker autoscaling. See Celery and RabbitMQ and prefetch count.
Decoupling microservices	Durable queues buffer messages while a consumer is down or deploying, so the producer keeps working.	A backlog nobody watches grows until it hits a disk or memory alarm and the broker blocks publishers. Set queue length limits and alert on queue depth and consumer count.
RPC and request-reply	The `reply_to` and `correlation_id` properties, or Direct Reply-To, where the caller consumes from the `amq.rabbitmq.reply-to` pseudo-queue and no reply queue is created.	The caller still waits on a remote service. Set client-side timeouts, and do not route latency-critical synchronous calls through a broker by default.
Publish/subscribe fan-out	A fanout or topic exchange with one queue per subscriber, so each service gets its own copy and consumes at its own pace.	Every subscriber queue stores its own copy. For very large fan-outs, RabbitMQ's documentation points to streams rather than quorum queues.
Routing by topic or headers	Topic exchanges match routing keys such as `orders.eu.created` against patterns with `*` (one word) and `#` (zero or more words); headers exchanges match on header values.	Binding sets grow until nobody knows which messages reach which queue. Keep the topology in code or definitions files and review it.
IoT and devices over MQTT	The MQTT plugin (`rabbitmq-plugins enable rabbitmq_mqtt`) supports MQTT 3.1, 3.1.1 and, since RabbitMQ 3.13, 5.0. QoS 0 subscribers can use a pseudo-queue type that stores nothing on disk.	Every device is a long-lived connection. Size file descriptors, memory and TLS termination for the device count, not the message rate.
Streams for replay	Streams (since 3.9) are replicated, append-only logs that many consumers read from any offset. Super streams (3.11) partition them; consumer-side filtering arrived in 3.13.	Retention has to be set deliberately, and full throughput needs a stream protocol client. See the RabbitMQ streams guide.
Delayed delivery and retries	Per-queue TTL plus a dead letter exchange; the quorum queue delivery limit (20 by default since 4.0) dead-letters poison messages; 4.3 adds delayed retry with increasing backoff for returned messages.	The delayed message exchange plugin is no longer maintained, and RabbitMQ says native delivery delay arrives in quorum queues in 4.4. Until then, use TTL and dead lettering. See our dead letter queue guide.
AI agent and LLM task queues	Queues between agents, tools and model workers, with prefetch as back-pressure so slow model calls do not pile up in memory.	Model calls are slow and expensive, so redelivery after a timeout means a duplicate call. Make handlers idempotent. See RabbitMQ for AI agents.

Which queue type for which job

Most of the catches above come down to choosing the right queue type, and that choice changed in RabbitMQ 4.0:

Quorum queues are the default choice for a replicated, highly available queue. They use Raft, and suit long-lived queues that matter to the business, such as order processing.
Classic queues are now non-replicated. Classic queue mirroring was removed in 4.0 after three years of deprecation, so mirroring policies have no effect after an upgrade. Use classic queues for temporary, exclusive or lowest-latency queues.
Streams fit large fan-outs, replay and very large backlogs. RabbitMQ's documentation advises against quorum queues for backlogs of millions of messages.

The cluster's metadata moved to Raft as well. Khepri became the default metadata store in 4.2, and in 4.3 Mnesia was removed, so a majority of nodes must be online for the cluster to be available. Three-node clusters tolerate one node down, five tolerate two.

# Declare a replicated work queue (AMQP 0-9-1 argument)
x-queue-type: quorum

# Or make quorum the default for queues declared without a type (rabbitmq.conf;
# a virtual host default takes precedence)
default_queue_type = quorum

Our comparison of classic vs quorum queues covers the migration.

Where RabbitMQ is the wrong tool

Retaining events for months and replaying them across many teams. Streams cover replay, but at that scale Kafka's partitioned log and tooling usually fit better. See RabbitMQ vs Kafka.
Caching or shared state. A queue is not a lookup store; Redis is. Our RabbitMQ vs Redis comparison draws the line.
Holding tens of millions of messages as a database. Large backlogs slow recovery and use disk fast. If messages sit for days, fix the consumers or move the data to storage built for it.
Synchronous, latency-critical APIs. RPC over a broker adds a hop and a failure mode; a direct HTTP or gRPC call is often simpler.

For the full list of options, see RabbitMQ alternatives, and for the honest counter-arguments, why not use RabbitMQ.

When to get help

Most RabbitMQ incidents trace back to one of the catches above: a backlog that triggered a memory alarm, consumers stuck behind a timeout, mirroring policies that silently stopped protecting anything after a 4.0 upgrade, or a cluster that lost its majority. AceMQ's RabbitMQ support engineers review how your queues are set up for the jobs they actually do and take the call when they misbehave, and RabbitMQ managed services cover running the brokers for you.

Sources

Frequently Asked Questions

What is RabbitMQ used for?

Mostly as a task queue for background work, such as Celery jobs, and to decouple microservices so one service can send work without waiting on another. It is also used for request-reply (RPC), publish/subscribe fan-out, routing by topic or headers, IoT messaging over MQTT, replayable streams and delayed retries.

What is RabbitMQ in simple terms?

A server that sits between applications and holds messages for them. A producer publishes a message to an exchange, the exchange routes it to one or more queues, and a consumer takes it from the queue and acknowledges it when the work is done.

Is RabbitMQ still maintained?

Yes. RabbitMQ 4.3, the current release series, was first released on 23 April 2026 and receives regular patch releases. It removed the old Mnesia metadata store in favour of Khepri and added delayed retry and strict priorities to quorum queues.

What is the difference between RabbitMQ and Kafka?

RabbitMQ is a broker that routes each message to queues and deletes it once consumed, which suits task queues and per-message routing. Kafka is a partitioned log that keeps events for a retention period so many consumers can read and replay them, which suits event streaming at high volume.

Does RabbitMQ support delayed messages?

Not natively in 4.3 for arbitrary delays. The common pattern is a queue with a message TTL that dead-letters into the real queue. The delayed message exchange plugin is no longer maintained, and RabbitMQ says quorum queues gain native delivery delay in 4.4.

Does Celery need RabbitMQ?

No, but RabbitMQ is Celery's default broker and needs no extra dependencies. Redis is the other common choice. With RabbitMQ quorum queues, Celery's documentation notes that global QoS must be disabled, which turns off worker autoscaling.

Guides, comparisons and research