RabbitMQ offers three queue types—classic queues, quorum queues, and streams—and choosing among them determines whether your messages survive a node failure. Classic queues are fast but unreplicated, quorum queues replicate via Raft with mandatory fsync, and streams trade immediate fsync for throughput up to one million messages per second. This guide explains what each type does, when it was introduced, and which workload it fits.
What RabbitMQ queue types exist and why they differ
RabbitMQ has three queue types today: classic queues, quorum queues and streams. Classic queues are the original 2007 model, fast but bound to a single node. Quorum queues, added in version 3.8 in 2019, replicate through the Raft consensus algorithm and only confirm writes after a majority fsyncs to disk. Streams, added in version 3.9 in 2021, are an append-only, Kafka-inspired log built for replay, retention and very high throughput. The differences trace back to the CAP theorem: mirrored classic queues favored availability and could serve stale data, while quorum queues and streams favor consistency by requiring quorum confirmation.
The evolution happened because demands changed. As covered in a Full Cycle video by Luiz Carlos, once workloads needed more scalability, reliable delivery and message retention, the older model stopped being enough. Current details below follow the official RabbitMQ documentation.
Classic queues: fast, simple, and unreplicated
Classic queues are the default queue you declare in code or through the management UI, and they remain the primary type for common distributed-systems patterns. They support work queues for background tasks such as video encoding or report generation, pub/sub with messages routed to thousands of consumers through exchanges, and request-reply using an exclusive in-memory response queue attached to the message.
They can run in two storage modes. Disk mode survives broker restarts but writes slowly and reduces throughput. Memory mode is much faster but loses messages on failure. The core limitation is structural: classic queues have no replication. Even in a cluster, the queue lives on one node, so if that node fails, publishing and consuming stop until it returns, and performance is capped by that single node's capacity. Scaling means adding CPU and memory vertically rather than adding nodes.
In newer RabbitMQ versions the intended role of classic queues is narrow: request-reply, message migration with the shovel plugin, or scenarios where losing messages is acceptable.
What happened to classic mirrored queues
Classic mirrored queues, introduced in 2011, replicated a classic queue across multiple cluster nodes to add availability and reliability. Through RabbitMQ 3.7 they were the recommended way to get durability and scale, because load was spread across replicas.
They carried serious problems under high load. Synchronization between nodes was slow and could leave the queue unavailable for long periods. Synchronization was blocking, freezing both publishers and consumers during the process. Storage needed constant reindexing on every publish, consume and removal, generating heavy disk writes that degraded performance. They could also serve stale data if a node holding newer messages failed before replication completed.
With the arrival of quorum queues and the replacement of the internal Mnesia database with Khepri, mirrored queues became obsolete. Deprecation started in version 3.9, and removal was completed in version 4.0, as documented in the RabbitMQ 4.0 release notes. Plain classic queues still work normally. If you lose messages despite manual acknowledgements, publisher confirms and persistent messages, mirrored replication was a likely cause.
Quorum queues: Raft consensus and strong durability
Quorum queues, available since RabbitMQ 3.8 in 2019, are the recommended choice when you need high reliability in production and consumption, or when migrating away from mirrored queues. Every operation must be confirmed by a majority of nodes before it counts, which eliminates state divergence and silent message loss. The design follows the Raft consensus algorithm, also used by etcd in Kubernetes and by HashiCorp Consul.
Under the hood, quorum queues use a write-ahead log. Every operation is first appended sequentially, which is fast, and later written to segment files. With publisher confirms enabled, RabbitMQ only confirms a publish after the quorum fsyncs the message to disk, the same fsync the operating system performs to guarantee bytes are physically written. Mirrored queues never gave that guarantee.
Despite the quorum requirement, quorum queues usually deliver higher throughput than mirrored queues did, thanks to efficient write-ahead-log I/O and the removal of the old synchronization bottlenecks. Reported figures in the tens of thousands of messages per second come from community comparisons like the Full Cycle video, not from official RabbitMQ benchmarks.
Streams: an immutable log for one million messages per second
A stream is an append-only, replicated message log built for very high throughput — roughly one million messages per second. Unlike classic and quorum queues, it keeps messages after consumption, lets multiple consumers read independently, and manages retention by age or size, making it RabbitMQ's answer to log-based systems.
Streams, launched in RabbitMQ 3.9 in 2021 and inspired by Apache Kafka, target the scenarios where quorum queues struggle: millions of messages and heavy simultaneous publish and consume. Messages are appended directly to segment files, never deleted on consumption, which simplifies I/O. Consumer groups all read from the same stream with no routing configuration, enabling replay, event reprocessing, auditing and retention of days to months, set by a simple retention parameter.
The consumption model inverts the default. Classic and quorum queues push messages to consumers, with the broker pacing them via prefetch. Streams let the consumer control its own reading pace, removing acknowledgement and reindexing overhead. Consumers periodically store their offset so they can resume after failures. See the official streams documentation for protocol details.
Streams still use Raft for replication, so a quorum of nodes confirms each operation. The key difference is durability: streams sacrifice the immediate fsync. New messages are first held in a memory buffer, and the operating system flushes to disk afterward. An abrupt failure can lose that buffer, a small and rare window of data loss. That cost buys the headline throughput of around one million messages per second cited in the Full Cycle comparison, which is well above the tens of thousands per second typical for quorum queues in the same comparison.
How to choose between quorum queues and streams
Choose quorum queues when losing a message is unacceptable, even on unstable infrastructure or with producers that cannot handle retries and republishing. Choose streams when your bottleneck is throughput or architecture: routing that has grown too complex, consumers that cannot keep queues empty, or a need to retain and replay messages over time.
The table sums up the decision:
| Type | Introduced | Replication | Durability guarantee | Best fit |
|---|---|---|---|---|
| Classic | 2007 | None | Optional persistence, no cross-node guarantee | Request-reply, transient or in-memory queues, shovel migrations |
| Quorum | 3.8, 2019 | Raft quorum | Confirm after majority fsync | Reliable production and consumption, mirrored-queue migration |
| Stream | 3.9, 2021 | Raft quorum | Quorum confirm, fsync deferred via memory buffer | High throughput, replay, auditing, long retention |
There is no perfect choice. Whichever type you pick, the surrounding infrastructure, configuration and error handling have to match it, because the choice directly affects how reliable your system is under failure.
FAQ
- Are classic queues deprecated in RabbitMQ?
No. Plain classic queues still work and are still the default. Only classic mirrored queues were deprecated in 3.9 and fully removed in version 4.0.
- When should I use quorum queues instead of classic queues?
Use quorum queues whenever you need replication and cannot tolerate message loss, for example reliable production pipelines. Classic queues remain fine for lightweight cases such as request-reply, transient queues, or scenarios where losing messages does not matter.
- Can RabbitMQ streams lose messages?
They can, in a small window. Streams confirm writes at quorum but defer the fsync to disk, keeping new messages in a memory buffer briefly. An abrupt broker failure during that window can lose buffered messages, a tradeoff made for throughput.
- Why were classic mirrored queues removed?
Their synchronization was slow, blocking and could leave queues unavailable under load, with heavy disk reindexing and no fsync guarantee. Quorum queues solve the same problem with Raft consensus and better performance, so mirroring became obsolete from version 3.8 onward.
- How fast are streams compared to quorum queues?
In the Full Cycle comparison, streams reach around one million messages per second while quorum queues deliver tens of thousands. These are community-reported figures for that comparison's setup, not official RabbitMQ benchmarks for all workloads.
From video to written reference
This article started as a Portuguese video by Luiz Carlos on the Full Cycle channel, walking through classic, quorum and stream queues with practical pros and cons. Picking the right queue type is exactly the kind of decision that deserves a written, searchable reference you can link your team to, and a 24-minute video is hard to skim when you just need the fsync tradeoff.
If you have explanations like this inside your own YouTube videos, you can turn them into structured articles with Skala Blog. Paste the video URL, get a transcription, and generate a publishable article that keeps the technical detail and loses the vinheta.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits