What is the difference between RabbitMQ Classic, Quorum, and Stream queue types?

RabbitMQ's three queue types serve different use cases. Classic queues: the original queue type. Two sub-types: non-replicated (data on one node) and mirrored (deprecated — async replication to mirrors with known data loss risks on failover). Still supported but Quorum queues are preferred for new deployments. Best for: simple use cases, existing deployments. Limitations: potential message loss on node failure (non-mirrored), complex mirror sync issues. Quorum queues: replicated using Raft consensus. Majority must acknowledge before a write is confirmed. Zero message loss on failover — any committed message is always available in the new leader. Best for: most production use cases requiring durability and high availability. Limitations: higher write latency (Raft overhead), more disk usage (Raft log), all nodes must be RabbitMQ 3.8+. Stream queues: append-only log with consumer offset tracking. Messages retained until size/time limit. Multiple independent consumers, replay from any offset. Best for: high-throughput event streaming, audit logs, event sourcing, Kafka-like use cases. Limitations: different consumer API (stream protocol preferred), higher complexity. Choose Quorum for task queues; Stream for event streaming.