ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Developer tools · #rabbitmq
Decision guide for RabbitMQ high-availability: compare Classic Mirrored vs. Quorum queues, analyze Raft-based consistency trade-offs, and validate automatic failover.
Learn how to implement RabbitMQ Quorum Queues using the Raft algorithm to ensure data consistency and high availability over legacy mirrored queues.
Dead Letter Exchanges let RabbitMQ route failed messages to a dedicated queue for inspection, retry, or archive. This guide shows how to configure DLX, verify its behavior, and avoid common pitfalls with a concrete example.
Quorum queues use Raft consensus to replicate RabbitMQ messages across nodes. Here's how to declare one, prove failover works, and decide when the latency trade-off is worth it.
Learn how to choose between transient, durable, and quorum queues in RabbitMQ to balance data safety against system throughput and I/O performance.
We are planning an in-place RabbitMQ upgrade and need a rollback plan before we proceed. From the documentation, a node whose data directory has been migrated by a newer version cannot simply be downgraded, and many feature flags cannot be disabled once enabled. So a binary rollback of the same cluster appears to be off the table. Our current thinking is to
We need to change immutable queue arguments (for example x-queue-type and max-length) on a set of classic queues in production. Since redeclaring with different arguments raises 406 PRECONDITION_FAILED, the plan is a blue-green approach: declare new queues and bindings alongside the old ones, move consumers over, then remove the old topology. The unresolved