Kafka, RabbitMQ ou SQS: como decidir?

A pergunta “qual broker é melhor?” quase sempre esconde uma pergunta mais útil: o que precisa acontecer com essa informação depois de publicada? A resposta muda conforme a necessidade é distribuir trabalho, manter um histórico reproduzível ou desacoplar serviços com o menor custo operacional possível.

Quando Kafka faz sentido

Kafka é especialmente forte quando eventos precisam permanecer disponíveis para mais de um consumidor e para reprocessamento posterior. O log retido permite que um novo consumidor leia o passado, que uma correção recalcule projeções e que diferentes equipes usem o mesmo fluxo em ritmos próprios.

Esse modelo pede decisões sobre partição, chave de ordenação, evolução de schema e capacidade de consumidores. A ordem só é garantida dentro da partição; aumentar paralelismo pode alterar essa escolha. É uma ferramenta poderosa, mas exige disciplina de operação e governança de contratos.

Quando RabbitMQ faz sentido

RabbitMQ funciona muito bem como fila de trabalho e roteador de mensagens. Exchanges, bindings, acknowledgements e políticas de entrega ajudam quando a prioridade é entregar uma tarefa para quem vai executá-la, com padrões de roteamento claros e baixa latência.

Ele costuma ser uma escolha direta para comandos assíncronos, tarefas de background e integrações internas. Reprocessamento histórico em grande escala não é seu caso de uso central; tratar uma fila como arquivo de eventos geralmente cria retenção e operação inadequadas.

Quando SQS e SNS fazem sentido

SQS reduz bastante o trabalho operacional para equipes já na AWS. É uma fila gerenciada, elástica e adequada quando o objetivo é desacoplar produtores e consumidores sem administrar clusters. SNS complementa o desenho quando uma publicação precisa chegar a múltiplos destinos.

Em troca, características como ordenação, atraso, visibilidade e reprocessamento dependem do tipo de fila e das configurações escolhidas. Uma FIFO pode resolver uma ordem por grupo, mas muda o perfil de throughput. DLQ também precisa ter uma estratégia de leitura e retorno — não deve virar armazenamento permanente de problemas.

Uma matriz de decisão curta

Escolha pelo comportamento desejado:

• preciso reter e reproduzir eventos? Kafka tende a se encaixar melhor;
• preciso distribuir tarefas e rotear mensagens? RabbitMQ é um candidato natural;
• quero uma fila gerenciada com integração AWS? SQS/SNS reduz a superfície operacional;
• preciso de ordem? defina antes a chave que realmente precisa ser ordenada;
• preciso recuperar falhas? desenhe idempotência, DLQ e reprocessamento antes do primeiro deploy.

Nenhuma dessas tecnologias remove a necessidade de contratos, observabilidade e um modelo de falhas. A ferramenta certa é a que torna essas decisões mais simples para o problema que você realmente tem.