Classic, Quorum ou Stream? RabbitMQ: tipos de filas Classic, Quorum, Stream
Tutorial técnico completo com exemplos práticos para escolher o tipo certo de fila RabbitMQ
Por que isso é importante
RabbitMQ tipos de filas: Classic = leve e single-replica (4.x sem mirror). Quorum = Raft/HA para pedidos e billing. Stream = log append-only com replay. Escolha por risco de perda × padrão de consumo — declare com x-queue-type; ~5k quorum queues pedem redesign de topologia.
Leitura relacionada: checklist de backend pleno · curso de Node.js · Clean Vertical Sliced Architecture · como criar API REST com Node.js · gateway de pagamento com Node.js.
Escolha certa = sistema estável RabbitMQ: tipos de filas Classic, Quorum, Stream
Aprenda as diferenças técnicas entre Classic, Quorum e Stream Queues com exemplos práticos e critérios de decisão.
Tipos de Filas RabbitMQ
Três tipos: Classic (simples, sem mirror no 4.x), Quorum (Raft/HA) e Stream (replay). Escolha pelo risco de perda e se precisa de consumo tipo log — não pelo hype Kafka.
Classic Queue
Fila tradicional AMQP. A partir do RabbitMQ 4.0 a Classic não tem mirroring — é single-replica. Simples e rápida quando perda é tolerável; para HA use Quorum ou Stream.
Quorum Queue
Fila com replicação nativa baseada em consenso (Raft). Alta confiabilidade e durabilidade para produção — reduz risco de perda frente a Classic, sem prometer “perda zero” em todo modo de falha.
Stream Queue
Fila baseada em logs imutáveis. Altíssimo throughput, leitura concorrente e retenção longa. Ideal para processamento de grandes volumes.
Comparativo Classic, Quorum, Stream
Veja os critérios técnicos essenciais para escolher sua fila
Escalabilidade
Streams vencem em volume, Quorum garante consistência e Classic exige escala vertical
Confiabilidade
Quorum garante fsync por quorum. Classic depende de persistência em disco. Streams são bufferizados
Performance
Streams lideram em throughput. Classic é rápida em memória. Quorum é consistente com custo de I/O
Reprocessamento
Apenas Streams permitem replay natural por offset. Classic e Quorum descartam após consumo
Quando usar cada fila?
Faça escolhas certeiras com base em throughput, confiabilidade e retenção
Clássica
Recomendada para testes, filas efêmeras, uso exclusivo em memória e onde perda de mensagens é tolerada. Performance alta com menos confiabilidade.
Quorum
Ideal para produção crítica: pedidos, mensagens financeiras, logs transacionais. Tolerância a falhas de nós com consistência garantida.
Stream
Para sistemas com alto tráfego, com auditoria, reprocessamento ou múltiplos consumidores concorrentes. Retém histórico e permite offset.
Matriz de decisão: latência, durabilidade e replay
Critério = risco de perda × padrão de consumo, não preferência de marketing. Resumo alinhado às docs RabbitMQ / CloudAMQP:
| Tipo | Latência / HA | Quando usar |
|---|---|---|
| Classic | Baixa latência; em 4.x single-replica (sem mirror) | Filas efêmeras / perda tolerável |
| Quorum | Raft entre nós; reduz risco vs Classic — não é “perda zero” | Hop que precisa sobreviver a falha de nó |
| Stream | Append-only com offset/replay e fan-out | Auditoria e reprocessamento (não é drop-in de Kafka) |
Throughput real depende de hardware e topologia. Em clusters grandes, revise a quantidade de quorum queues (ordem de ~5k é um sinal para revisar desenho — não há “hard limit de 40k msgs” nas docs).
RabbitMQ 4.x: Classic sem mirror, Quorum para HA
A partir do RabbitMQ 4.0, mirroring de Classic foi removido. Classic continua suportada, mas sem réplicas: políticas de mirror antigas não têm efeito. Se o hop exige alta disponibilidade, declare Quorum (x-queue-type: quorum) ou use Streams quando o padrão for retenção/replay. Guia oficial: Quorum Queues e notas de release 4.0.
Migração típica: consumir/mover mensagens da Classic antiga → deletar → redeclarar como Quorum com o mesmo nome (tipo não muda in-place). Faça isso antes ou logo após o upgrade 4.x se o tráfego for crítico.
Cenário: pedido, billing e notify (um hop por tipo)
Mini saga didática (Node + amqplib): pedido/billing → Quorum; auditoria/replay → Stream; notify “best effort” → Classic. Exemplo de declaração:
await ch.assertQueue('orders.billing', {
durable: true,
arguments: { 'x-queue-type': 'quorum' },
});
await ch.assertQueue('orders.audit', {
durable: true,
arguments: { 'x-queue-type': 'stream' },
});
await ch.assertQueue('orders.notify', {
durable: false,
arguments: { 'x-queue-type': 'classic' },
});Consumer de billing com ack manual e publisher confirms; consumer de audit lê por offset quando precisar reprocessar; notify pode dropar em restart sem derrubar o pedido. Ajuste nomes e DLX ao seu domínio.
Fontes
Revisão em agosto de 2026. Classic (sem mirroring desde 4.0), Quorum (Raft) e Streams seguem a docs RabbitMQ — throughput real depende de hardware/cluster; sem “perda zero” absoluto nem limite inventado de mensagens.
RabbitMQ — Quorum Queues · RabbitMQ — Streams · RabbitMQ — Queues.
Perguntas frequentes
Quais são os tipos de filas do RabbitMQ?
Os três tipos principais são Classic, Quorum e Stream. Declare com x-queue-type: classic é leve e single-replica (desde 4.0); quorum usa Raft para HA; stream é log append-only com replay.
Quando usar Quorum Queue no RabbitMQ?
Use Quorum quando a mensagem importa e você aceita o custo de réplicas/consenso. Reduz risco frente a Classic, mas não é “perda zero” absoluto — revise topologia (~5k quorum queues pedem redesign).
Stream queue do RabbitMQ substitui Kafka?
Não como drop-in. Stream cobre log/replay e fan-out no ecossistema Rabbit; Kafka mantém tooling e escala próprios. Escolha por retenção, consumidores e operação do time.
Classic Queue ainda tem mirroring no RabbitMQ 4?
Não. Mirroring de Classic foi removido no RabbitMQ 4.0 — Classic fica single-replica. Para HA, migre para Quorum ou Stream.
Continue explorando: checklist de backend pleno · curso de Node.js · Clean Vertical Sliced Architecture · como criar API REST com Node.js · gateway de pagamento com Node.js.