RabbitMQ in Production

Durable queues survive a broker restart (their definition is persisted); transient queues vanish. Durability is necessary but not sufficient for "don't lose data" — pair it with persistent messages and, for anything replication-worthy, a quorum queue. See Fundamentals for how publisher confirms and consumer ACKs fit into the full picture.

x-max-length and x-max-length-bytes cap how large a queue can grow, dropping or dead-lettering the oldest messages once the limit is hit. Essential for queues that could otherwise grow unbounded during an outage.

x-message-ttl expires messages after a fixed time, useful for things like OTP codes or cache invalidation events where a stale message is worse than a missing one.

RabbitMQ's modern replicated queue type, based on Raft consensus — the recommended default for anything durability-sensitive. Classic queues remain a legitimate, non-replicated choice for high-churn or throughput-sensitive workloads where replication isn't required. See the High Availability chapter for replica-count and failover detail.

A DLQ with zero messages is healthy. A DLQ that's growing is an active incident. Wire DLQ depth into monitoring with a low alert threshold — for a low-volume queue that should rarely see failures, even a single message can be worth an alert; tune the threshold to the queue's normal failure rate.

Build (or buy) tooling to inspect a DLQ message, understand why it failed, fix the root cause, and republish it to the original queue. Manual rabbitmqadmin fiddling doesn't scale past a handful of incidents.

A common pattern: route failed messages to an intermediate 'retry' queue with a message TTL and no consumers; when the TTL expires, its own DLX routes the message back to the original queue. This gives exponential-backoff-like behavior using only core RabbitMQ primitives — choose TTL values based on your downstream's actual recovery time, not a fixed formula.

Track attempts via a custom header incremented on each retry, or read the broker-maintained x-death array for the dead-letter count. Cap at N attempts, then route to the terminal DLQ instead of retrying again.

Replicate queue contents across a configurable number of nodes (the queue's "replica set" or group size — commonly 3) using the Raft consensus protocol. A minority of that replica set can fail without data loss, though a leader failover can cause a brief interruption while a new leader is elected — it is not instant or invisible. This is the replicated queue type, replacing classic mirrored queues.

The older HA mechanism — a queue's master replicated to mirrors on other nodes. Classic queue mirroring was deprecated and has been removed as of RabbitMQ 4.0. Classic queues themselves still exist and remain a valid non-replicated choice; they simply no longer have a mirroring/HA mode. Quorum queues are the replicated option now. See the quorum queues documentation.

For multi-datacenter or multi-region topologies, RabbitMQ's Federation plugin forwards messages between independently-administered brokers/exchanges — it is not the same replication mechanism as quorum queues, and brokers stay independently managed. Shovel moves messages between queues/brokers point-to-point. Both trade strict consistency for geographic reach.

The single most actionable pair of metrics: a growing queue with zero (or too few) consumers relative to its normal baseline is either an outage or a capacity shortfall — alert on that pattern rather than a fixed queue-depth number, since normal depth varies a lot by queue.

A sustained high unacked count suggests slow consumers, a stuck consumer holding messages without acking, or overly high prefetch.

RabbitMQ can throttle or block publishing when memory or disk high-watermarks are hit — this can appear as publish stalls or added latency rather than explicit errors, so it's worth watching the alarm state directly rather than only error rates.

A deploy, crash, or scaling event takes all consumers offline; the queue grows unbounded until they return. Mitigate with autoscaling on queue depth and alerting on consumer count = 0.

Once a resource alarm triggers, RabbitMQ can throttle or block publisher connections until memory/disk drops below the watermark — depending on topology this can affect publishing broadly enough to look like "everything is frozen" from the application's perspective. Confirm current behavior against the alarms documentation for your RabbitMQ version when diagnosing this.

As covered earlier — a DLQ with no consumer and no TTL/max-length policy silently fills disk over weeks until the alarm above triggers.

Client bugs that open a new connection or channel per request without closing it exhaust file descriptors on the broker, eventually rejecting new connections entirely.

Fastest way to see queue depth, consumer count, and memory per queue from the command line — invaluable when the management UI itself is slow under load.

rabbitmq_tracing logs every message passing through the broker (with performance cost) — use it temporarily to answer "is this message actually reaching the exchange?" during a routing mystery.

For multi-broker topologies, check shovel/federation link status first when messages seem to be routing correctly locally but not arriving at a remote broker.