Kafka vs RabbitMQ para automações: quando usar fila, quando usar stream (sem dor de cabeça)
- RabbitMQ é orientado a filas (work queues) e confirmações; Kafka é um log de eventos com retenção e replay
- Retries e DLQ existem nos dois, mas o “jeito” de fazer muda bastante
- Kafka costuma exigir mais disciplina operacional (clusters, particionamento, observabilidade)
- Para automação com n8n/Make e integrações HTTP, filas resolvem 80% dos casos; stream vira necessário quando você precisa reprocessar e alimentar múltiplos sistemas
O que muda de verdade (não a teoria bonita)
Em automação, “fila” geralmente significa: pegar uma tarefa, processar, confirmar (ack) e, se falhar, tentar de novo. Esse é o território natural do RabbitMQ.
Já “stream” é: registrar eventos (pedido criado, pagamento aprovado, lead atualizado) em um log que pode ser lido por diferentes consumidores, em ritmos diferentes, com possibilidade de replay. Esse é o jeito Kafka.
Comparativo rápido: Kafka vs RabbitMQ
Se você está decidindo para um ambiente com automações, integrações e agentes/robôs, compare pelo comportamento operacional e pelas garantias que importam no seu fluxo (duplicidade, ordem, reprocessamento).
| Critério | RabbitMQ (fila) | Kafka (stream/log) |
|---|---|---|
| Modelo mental | Tarefas em fila para workers consumirem | Eventos em tópicos com retenção |
| Reprocessar mensagens antigas | Não é o padrão; depende de como você guardou/roteou | É nativo: replay por offset/retenção |
| Ordem | Ordem por fila (com nuances quando há paralelismo) | Ordem por partição (você define a chave) |
| Retries / DLQ | Comum e direto (exchanges/queues dedicadas, TTL, dead-lettering) | Normalmente feito por tópicos de retry/DLQ e política do consumidor |
| Vários consumidores independentes | Possível, mas nem sempre elegante (fanout/pub-sub existe) | Feito para isso (consumer groups, múltiplas aplicações) |
| Operação | Geralmente mais simples de começar e manter em menor escala | Tende a exigir mais governança (partições, retenção, balanceamento) |
| Quando costuma dar ruim | Explosão de retries sem backoff, filas crescendo sem capacidade | Particionamento mal pensado, reprocesso sem idempotência, custos/complexidade de cluster |
Quando escolher RabbitMQ (cenários de automação bem reais)
RabbitMQ costuma ser a escolha pragmática quando você quer confiabilidade no “trabalho a fazer” (jobs) e não quer transformar sua automação num projeto de plataforma.
- Envio de mensagens (e-mail/WhatsApp) em lote com controle de ritmo e tentativas
- Processamento de pedidos (emitir NF, atualizar estoque, gerar etiqueta) com confirmação por etapa
- Integrações com APIs instáveis: você precisa de backoff, reenqueue e visibilidade de falhas
- Pipelines com workers múltiplos, mas sem exigência de replay histórico longo
Quando escolher Kafka (e quando ele vira inevitável)
Kafka vale quando seus eventos precisam virar um “sistema nervoso” da operação: vários consumidores, reprocessamento frequente e histórico para reconstruir estado. É menos sobre “rodar um workflow” e mais sobre “distribuir eventos com governança”.
- Você tem muitos sistemas consumindo os mesmos eventos (CRM, BI, antifraude, automações, data lake)
- Reprocessar é parte do dia a dia (corrigiu regra, reexecuta o passado sem pedir para cada sistema guardar log)
- Você precisa desacoplar times e serviços: produtores não devem saber quem consome
- Você já tem cultura de observabilidade e operação 24/7 (ou precisa ter)
Checklist de decisão (5 perguntas que evitam escolha errada)
Antes de cair na tentação do “mais robusto”, responda com honestidade:
- Você precisa reprocessar eventos antigos com frequência ou só re-tentar falhas recentes?
- Quantos consumidores independentes vão existir para o mesmo dado (hoje e em 12 meses)?
- Qual é sua tolerância a duplicidade? Seu fluxo é idempotente de ponta a ponta?
- A ordem importa? Se sim, por qual chave (cliente, pedido, conversa, contrato)?
- Quem vai operar isso (alertas, capacidade, retenção, upgrades) quando der problema às 2h?
Dois cuidados que valem para os dois (e quase ninguém faz no começo)
1) Idempotência: se sua automação pode receber o mesmo evento duas vezes (e ela pode), o processamento precisa ser seguro para duplicatas. Normalmente isso envolve chave única (ex.: id do pedido) e registro do que já foi processado.
2) Backoff e circuit breaker: retry sem limite e sem espaçamento é uma fábrica de cascata de erro. É melhor falhar “com dignidade” (para DLQ/triagem) do que derrubar tudo tentando infinitamente.
Perguntas frequentes
Kafka substitui RabbitMQ em automações?
Qual é mais fácil de operar em uma empresa pequena?
E quanto a DLQ (Dead Letter Queue)?
Dá para usar n8n/Make com Kafka ou RabbitMQ?
Leia também
RabbitMQ vs SQS vs Redis Streams: qual fila escolher para automações (n8n, Make e integrações)
Comparativo prático entre RabbitMQ, Amazon SQS e Redis Streams para filas, retry e desacoplamento de automações. Veja prós, limites típicos e cenários reais (webhooks, picos, DLQ).
Ler →
Como usar Dead Letter Queue (DLQ) em automações: trate falhas sem perder eventos
Guia prático de Dead Letter Queue (DLQ) para automações: quando usar, como modelar eventos, reprocessar com segurança e evitar duplicidade em n8n/Make/Zapier.
Ler →
Circuit breaker em automações (n8n/Make/Zapier): como evitar cascata de erros quando uma API cai
Guia prático para aplicar padrão circuit breaker em automações no n8n, Make ou Zapier: quando abrir/fechar, como detectar falhas, fallback, filas e alertas para não derrubar sua operação.
Ler →
Como desenhar uma arquitetura de automação com filas, retry e idempotência (sem virar gambiarra)
Guia prático para desenhar automações resilientes: quando usar filas, como fazer retry/backoff, idempotência e DLQ. Evite duplicar pedidos, estourar rate limit e cair em loop infinito em n8n/Make/Zapier.
Ler →