Message broker: como escolher entre RabbitMQ, Kafka, SQS e Redis Streams

Escolher um message broker é uma das decisões de arquitetura que mais impactam a vida de um SaaS depois do primeiro ano: ele define como os serviços se comunicam, o que acontece quando algo falha e quanto de operação sua equipe vai carregar. Neste comparativo, olho para RabbitMQ, Apache Kafka, Amazon SQS e Redis Streams pelo ângulo de quem precisa decidir com poucos recursos e muita responsabilidade.

O que um message broker resolve (e o que não resolve)

Um message broker desacopla produtores e consumidores no tempo e na disponibilidade. O serviço de cobrança publica um evento e segue em frente, enquanto o serviço de notificações processa quando puder. Isso traz absorção de picos, retentativas e isolamento de falhas.

O que ele não resolve: consistência entre banco e fila (o clássico problema do dual write), idempotência no consumidor e modelagem ruim de eventos. Se você grava no banco e publica na fila em duas operações separadas, vai perder ou duplicar mensagens em algum momento. O padrão transactional outbox existe exatamente para isso.

Fila versus log: a diferença de modelo que importa

A distinção central entre qualquer message broker moderno é o modelo de armazenamento:

Fila (queue): a mensagem é entregue a um consumidor e removida após confirmação (ack). Ideal para distribuição de tarefas. RabbitMQ e SQS seguem esse modelo.
Log distribuído: as mensagens são anexadas a um log particionado e retidas por tempo ou tamanho; cada consumidor controla seu próprio offset. Ideal para eventos, reprocessamento e múltiplos consumidores independentes. Kafka é a referência; Redis Streams segue uma ideia parecida em escala menor.

Essa escolha pesa mais do que qualquer comparação de desempenho, porque define se você consegue reler o passado.

RabbitMQ

Implementa AMQP 0-9-1 (com suporte a outros protocolos via plugins) e oferece roteamento flexível por exchanges (direct, topic, fanout, headers). É excelente para filas de trabalho com prioridades, TTL, dead-letter exchanges e padrões de roteamento complexos. Para durabilidade e alta disponibilidade, o caminho recomendado hoje são as quorum queues, baseadas em Raft.

Prós: roteamento rico, baixa latência, ecossistema maduro, curva de aprendizado razoável.
Contras: reprocessamento histórico não é o foco (existem streams, mas é outro modelo); filas muito longas pressionam memória e disco; operar cluster exige atenção a partições de rede.

Apache Kafka

Kafka é uma plataforma de log distribuído. Tópicos são divididos em partições, a ordenação é garantida apenas dentro de cada partição e o paralelismo do consumidor é limitado pelo número de partições dentro de um consumer group. A retenção permite replay: um novo serviço pode ler o histórico desde o início.

kafka-topics.sh --create \
  --topic pedidos.criados \
  --partitions 6 \
  --replication-factor 3 \
  --bootstrap-server broker:9092

Prós: replay, alto throughput, múltiplos consumidores independentes, ótimo para event streaming e integração com CDC.
Contras: operação mais pesada (brokers, armazenamento, rebalanceamento de consumer groups), partições são difíceis de reduzir e a chave de particionamento mal escolhida causa hot partitions. Para um time pequeno, a versão gerenciada costuma compensar.

Amazon SQS

Serviço totalmente gerenciado, com filas Standard (entrega at-least-once, ordenação best-effort) e FIFO (ordenação por grupo de mensagens e deduplicação). Integra com dead-letter queues, visibility timeout e escala sem que você administre servidores.

Prós: zero operação de infraestrutura, escala simples, integração nativa com o restante da AWS.
Contras: sem replay após consumo, roteamento limitado (normalmente combinado com SNS para fan-out), dependência de um provedor específico e latência maior que brokers em rede local.

Redis Streams

Se você já roda Redis, Streams com consumer groups entrega um log simples, com confirmação via XACK e reivindicação de mensagens pendentes. Funciona bem para volumes moderados e pipelines internos.

Prós: baixa fricção, latência baixa, reaproveita infraestrutura existente.
Contras: durabilidade depende da configuração de persistência (RDB/AOF) e de replicação; retenção é limitada pela memória; ecossistema de conectores é menor que o do Kafka.

Critérios práticos de decisão

Ao avaliar um message broker, responda a estas perguntas antes de comparar benchmarks de terceiros:

Preciso reler eventos antigos? Se sim, log (Kafka ou Redis Streams) ou RabbitMQ Streams.
A ordem importa e em qual escopo? Ordem por entidade exige chave de partição (Kafka) ou grupo de mensagens (SQS FIFO).
Quantos consumidores independentes vão ler o mesmo evento? Muitos consumidores favorecem log; poucos e com tarefas distintas favorecem filas.
Quem vai operar isso às 3h da manhã? Se ninguém, priorize serviço gerenciado.
Qual o custo de lock-in aceitável? SQS é conveniente, mas prende a AWS; Kafka e RabbitMQ são portáveis.

Armadilhas que independem da ferramenta

Independentemente do message broker escolhido, a maioria dos incidentes vem do mesmo lugar: consumidores que não toleram duplicatas. Quase todos os brokers oferecem entrega at-least-once por padrão, então o consumidor precisa ser idempotente, por exemplo registrando o ID do evento processado em uma tabela com restrição de unicidade.

Defina uma dead-letter queue e alerte sobre seu crescimento.
Use backoff exponencial nas retentativas, não loops imediatos.
Versione o schema dos eventos (JSON Schema, Avro ou Protobuf) desde o início.
Monitore lag de consumidores e idade da mensagem mais antiga, não só CPU.

Em ambientes multi-tenant, considere também isolar tenants barulhentos com filas, tópicos ou chaves de partição separadas, para que um cliente grande não degrade todos os outros.

Recomendação por cenário

Tarefas assíncronas simples (e-mails, webhooks, relatórios): SQS ou RabbitMQ.
Roteamento complexo e prioridades: RabbitMQ.
Event streaming, CDC, analytics e vários consumidores: Kafka, preferencialmente gerenciado se o time for enxuto.
MVP ou pipeline interno com Redis já em produção: Redis Streams, com plano de migração se o volume crescer.

Para um time pequeno, o message broker gerenciado costuma ser a escolha pragmática: o custo da operação própria raramente aparece na planilha, mas aparece no tempo de engenharia.

Conclusão

O melhor message broker é o que combina com o seu modelo de dados e com a capacidade operacional da sua equipe, não o que lidera o ranking de popularidade. Comece pela pergunta de replay e de ordenação, desenhe consumidores idempotentes e só então escolha a ferramenta. Decisões técnicas como essa também precisam ser comunicadas ao mercado; se você quer transformar esse tipo de conhecimento em conteúdo recorrente, veja como organizar um calendário editorial para SaaS.