RabbitMQ vs Redis as a message broker

Which broker fits which queue workload

This table maps common queue workloads to the better fit between RabbitMQ and Redis, with the condition that drives each choice. Read each row for the deciding factor, then check whether your own load, failure tolerance and operating model match it.

How RabbitMQ quorum queues and Redis replication differ in operation

RabbitMQ and Redis both keep queue traffic available through node failures, but they get there with different consensus models, node counts and operating routines. The cards below cover where each model puts the risk, what it asks of your team after go-live, and what to confirm in your own environment before you size a cluster.

Delivery, persistence and protocol capabilities compared

This table compares how Redis Pub/Sub, Redis Streams and RabbitMQ deliver, persist and replicate messages, and which protocols each accepts. Read each row against your current Redis version and client library, because delivery behavior depends on how your application uses the commands.

What the MPL-2.0 and Redis license changes mean for each option

What drives running cost for each broker

This table lists the cost drivers for running RabbitMQ or Redis as a queue, with no figures, since none are supplied for either product. Read each row as a question to answer in your own environment and in vendor quotes, because the largest differences come from replica count, memory sizing and which support tier you buy.

Moving queue traffic from Redis to RabbitMQ in order

This sequence moves queue traffic off Redis lists, Pub/Sub or Streams onto RabbitMQ without losing messages in flight, and ends with a documented retirement of the old path. Each step closes with a check the owning team can verify.

1. Inventory every producer and consumer

   Platform engineering and the owning application teams list every service that pushes to or pulls from Redis, including scripts, cron jobs and batch workers. For each one, record the Redis structure it uses (list, Pub/Sub channel or Stream with consumer groups), the message volume it handles, and any code that depends on Redis-specific behavior such as blocking pops or stream IDs. The step is done when every queue has a named owner and no client is unaccounted for in network or configuration review.

2. Define delivery and redelivery rules per queue

   For each queue, the owning team decides whether the workload can tolerate loss, duplicate delivery or only ordered single processing. Redis Pub/Sub is at-most-once, so any channel that carries work must be redesigned before it moves. Document the acknowledgement mode, the maximum redelivery attempts, and the expected behavior when a consumer crashes mid-message. The step is done when a written rule exists for each queue and the security and data owners have signed off on any queue that carries regulated data.

3. Model exchanges, queues and bindings

   Platform engineering designs the RabbitMQ topology: exchanges, routing keys, bindings and quorum queues for queues that need durability and replication. Decide early whether a workload needs a stream instead, since RabbitMQ streams suit high-throughput log-style consumption. Review the design with the consumer teams so that routing keys and queue names match what each consumer subscribes to. The step is done when a topology definition exists in version control and a test environment can declare it cleanly.

4. Rebuild the client and retry layer

   Application teams replace Redis client calls with an AMQP client library and wire in the new acknowledgement logic, retry policy, dead-letter exchange and alerting defined in the earlier steps. Message payloads and idempotency checks typically carry over, but the surrounding code does not, so teams should expect to rewrite connection handling and error paths. The step is done when each consumer passes integration tests against a non-production RabbitMQ cluster, including forced consumer failure and redelivery.

5. Run both paths in parallel

   Teams run dual publishing, where producers write to Redis and RabbitMQ at once, or move consumers one queue at a time with a cutover switch. Dual publishing keeps a rollback path but doubles write load, so confirm capacity with the platform team before enabling it. Compare message counts, processing results and error rates between the two paths for a period the owners agree on in advance. The step is done when the outputs match and the on-call team has run at least one planned failover test on the new broker.

6. Drain the Redis queues

   Once a consumer is switched, the team stops new publishes to the Redis structure and lets existing entries finish processing. For lists, confirm the length reaches zero. For Streams, confirm that every consumer group has acknowledged its pending entries, and inspect the pending entries list for stuck messages. Any messages that cannot be processed are moved to a reviewed holding queue rather than dropped. The step is done when the Redis key has no unprocessed entries and the owner signs off on the drain report.

7. Retire the old path and document the result

   Remove the Redis publishing code, consumer connections and dual-write logic, then delete the unused keys and update the architecture diagrams and runbooks. Record the final topology, the acknowledgement rules and the monitoring dashboards in the team's documentation, along with who owns each queue. Keep the Redis instance itself only for the uses that still need it, such as caching. The step is done when a configuration search finds no active Redis queue references and the runbook has been reviewed by the operations team.

Where a dedicated broker pays off for queue traffic

Questions teams ask before moving queues off Redis