Escolher um message broker é uma das decisões de arquitetura que mais cobram juros no futuro: ela define como seus serviços se acoplam, como falham e quanto custa operar o sistema depois de dois anos de crescimento.
Neste comparativo técnico, analiso Apache Kafka, RabbitMQ e Amazon SQS sob a ótica de quem opera sistemas reais: modelo de dados, garantias de entrega, ordenação, operação e custo. Não existe vencedor universal. Existe aderência ao seu caso de uso e à capacidade do seu time.
Fila ou log: o modelo mental que muda tudo
Antes de comparar produtos, separe dois modelos. No modelo de fila, o broker entrega a mensagem a um consumidor e a remove após o ack. No modelo de log distribuído, as mensagens são anexadas a uma estrutura append-only e permanecem disponíveis conforme a política de retenção, e cada consumidor controla seu próprio offset.
Essa diferença determina se você consegue reprocessar histórico, quantos consumidores independentes leem o mesmo fluxo e como o sistema escala. Todo message broker sério ocupa algum ponto desse espectro. Entender isso evita usar Kafka como fila de tarefas ou RabbitMQ como armazenamento de eventos.
Apache Kafka: log particionado para streaming de eventos
No Kafka, os dados são organizados em tópicos divididos em partições, replicadas entre brokers. A ordenação é garantida apenas dentro de uma partição, e os consumer groups distribuem as partições entre as instâncias de um serviço. Nas versões recentes, o modo KRaft dispensa o ZooKeeper para o gerenciamento de metadados, o que simplifica a operação. Como message broker orientado a log, ele brilha quando o evento é um fato que precisa ser lido por vários sistemas.
- Prós: replay de histórico, múltiplos consumidores independentes, bom throughput em escrita sequencial e ecossistema maduro (Kafka Connect, Kafka Streams).
- Contras: operação mais complexa (partições, rebalanceamento, disco), paralelismo limitado ao número de partições, roteamento simples e ausência de retry por mensagem nativo, o que exige tópicos de retry e DLQ.
Casos de uso: event sourcing, CDC (change data capture), pipelines de dados, telemetria e trilhas de auditoria.
RabbitMQ: roteamento flexível e filas de trabalho
O RabbitMQ implementa AMQP 0-9-1 e separa produtor de fila por meio de exchanges (direct, topic, fanout e headers) e bindings. Há acks por mensagem, controle de prefetch, dead-letter exchanges, TTL e prioridades. As quorum queues, baseadas em Raft, trazem replicação consistente, e os streams adicionam um modelo próximo ao de log. Como message broker de propósito geral, ele resolve bem a comunicação entre microsserviços.
- Prós: roteamento rico, semântica natural para filas de tarefas, retry e DLQ bem resolvidos e latência baixa em cargas típicas.
- Contras: a mensagem consumida desaparece (fora dos streams), backlogs muito grandes degradam o desempenho e a escala horizontal exige mais planejamento.
Casos de uso: processamento de jobs, integração entre serviços, workflows assíncronos e padrões request/reply.
Amazon SQS: fila gerenciada sem operação
O SQS é um serviço totalmente gerenciado. A fila standard oferece entrega at-least-once com ordenação best-effort. A fila FIFO garante ordenação por message group e oferece deduplicação. Recursos como visibility timeout, DLQ e long polling cobrem a maior parte das necessidades, e a combinação com SNS permite fan-out. Como message broker gerenciado, seu maior valor é eliminar a operação.
- Prós: zero administração de cluster, escala elástica e integração direta com Lambda e outros serviços AWS.
- Contras: lock-in na AWS, sem replay de histórico, roteamento limitado e restrições de throughput e de modelo nas filas FIFO. Consulte os limites atuais na documentação oficial.
Se você provisiona essa infraestrutura de forma declarativa, vale ler o review técnico do Terraform para times de TI, que mostra como versionar brokers, filas e permissões como código.
Como escolher o message broker certo
Em vez de comparar tabelas de features, responda a perguntas de arquitetura:
- Preciso reprocessar eventos antigos? Kafka, ou streams no RabbitMQ.
- Preciso de roteamento por padrão, prioridade e retry fino? RabbitMQ.
- Meu time é pequeno e a carga já roda na AWS? SQS.
- Há exigência de residência de dados ou de cloud nacional? Priorize brokers que você possa hospedar onde o compliance exigir.
Um ponto vale para os três: na prática, a entrega é at-least-once, então o consumidor precisa ser idempotente. Ordenação também é um contrato que você desenha: chave de partição no Kafka, message group no SQS FIFO ou fila única com um consumidor no RabbitMQ.
# Kafka: tópico com chave de ordenação por pedido
kafka-topics.sh --create --topic pedidos \
--partitions 6 --replication-factor 3 \
--bootstrap-server broker:9092
# Produtor: use order_id como key para manter a ordem por pedidoO melhor message broker é o que sua equipe consegue operar, monitorar e depurar às três da manhã. Kafka self-hosted cobra dedicação de time, enquanto serviços gerenciados trocam controle por conveniência. Para enxergar essa escolha dentro de um contexto maior de mercado, leia também Tendências do Mercado de TI: Como Antecipar Movimentos e Enriquecer.
Conclusão
Kafka é a escolha para eventos duráveis e reprocessáveis, RabbitMQ para roteamento e filas de trabalho, e SQS para simplicidade operacional na AWS. Antes de fechar a decisão sobre o message broker, faça uma prova de conceito com seu padrão real de mensagens, incluindo falhas, reentregas e picos de carga. É esse teste, e não um comparativo genérico, que mostra qual stack sustenta seu produto com o menor custo de operação.
