Filas e mensageria: quando usar Kafka, RabbitMQ ou SQS em arquiteturas distribuídas

Em um monólito, chamar outra parte do sistema é só invocar uma função. Em uma arquitetura distribuída, cada chamada vira uma requisição de rede que pode falhar, demorar ou chegar duas vezes. Acoplar serviços por chamadas síncronas diretas transforma cada dependência em um ponto de falha: se o serviço de e-mail cai, o checkout que o chama de forma síncrona cai junto.

A mensageria quebra esse acoplamento. Em vez de o serviço A esperar o serviço B responder, A publica uma mensagem e segue em frente; B consome quando puder. O resultado é um sistema mais resiliente, desacoplado e capaz de absorver picos. Mas "usar fila" não é uma decisão única: RabbitMQ, Kafka e SQS resolvem problemas diferentes, e escolher errado custa caro. Este guia mostra como decidir.

Dois paradigmas: broker de mensagens vs. event streaming

Antes das ferramentas, o conceito. Há duas famílias de mensageria, e confundi-las é a origem da maioria dos erros de arquitetura.

• Message broker (fila tradicional): a mensagem é uma tarefa a ser executada uma vez. Ela entra na fila, um consumidor a processa e ela some (é removida com o ack). O foco é entregar trabalho a workers. Exemplos: RabbitMQ, Amazon SQS.
• Event streaming (log de eventos): a mensagem é um fato que aconteceu e fica persistido em um log ordenado por um período. Vários consumidores independentes leem o mesmo evento, cada um no seu ritmo, e podem reprocessar o histórico do zero. Exemplo: Apache Kafka.

A pergunta que separa os dois: depois que a mensagem é consumida, ela deveria sumir ou continuar disponível para outros? Se é uma tarefa (enviar um e-mail), some: use um broker. Se é um fato do qual vários times querem derivar coisas diferentes (pedido criado), fica: use streaming.

Padrões de comunicação

Independentemente da ferramenta, dois padrões estruturam o fluxo:

• Work queue (competição por consumo): uma mensagem vai para um consumidor entre vários workers concorrentes. Serve para distribuir carga, como processar 10 mil thumbnails entre 20 workers.
• Publish/subscribe (fan-out): uma mensagem é entregue a todos os assinantes interessados. Um evento "pedido pago" dispara, em paralelo, o serviço de nota fiscal, o de estoque e o de e-mail.

RabbitMQ modela ambos via exchanges e bindings. Kafka faz fan-out naturalmente porque o evento persiste e cada consumer group lê independentemente.

As três ferramentas, lado a lado

Critério	RabbitMQ	Apache Kafka	Amazon SQS
Paradigma	Broker de mensagens	Event streaming (log)	Broker de mensagens (gerenciado)
Throughput	Alto	Altíssimo (milhões/s)	Alto, elástico
Retenção após consumo	Não (some no ack)	Sim (dias/semanas)	Não (some no delete)
Reprocessar histórico	Não	Sim	Não
Ordenação	Por fila	Por partição	FIFO (fila FIFO)
Roteamento complexo	Forte (exchanges)	Limitado	Simples
Operação	Você opera o cluster	Você opera o cluster	Totalmente gerenciado
Melhor para	Tarefas, RPC assíncrono, roteamento	Pipelines de eventos, analytics, event sourcing	Filas simples sem operar infra

RabbitMQ: o broker versátil

RabbitMQ brilha em roteamento flexível e entrega de tarefas. Suas exchanges (direct, topic, fanout) permitem regras sofisticadas de para quem cada mensagem vai. É a escolha natural quando você precisa de padrões de trabalho variados, prioridades, TTL por mensagem e roteamento por tópico, sem o peso conceitual de um log distribuído.

Apache Kafka: o log distribuído

Kafka é a espinha dorsal de arquiteturas orientadas a eventos. Como o evento persiste, ele viabiliza casos que um broker tradicional não faz: event sourcing, alimentar múltiplos consumidores (analytics, busca, data lake) do mesmo fluxo, e reprocessar meses de dados ao subir um novo serviço. O custo é operacional: é um sistema distribuído com partições, offsets e consumer groups para entender e operar.

Amazon SQS: a fila sem dor de operação

SQS entrega o valor de uma fila sem você operar cluster nenhum. Escala elasticamente, cobra por uso e some da sua lista de preocupações de infraestrutura. Tem duas variantes: Standard (throughput altíssimo, ordem não garantida, entrega at-least-once) e FIFO (ordem estrita e exactly-once por grupo, com throughput menor). Se você está na AWS e precisa de uma fila de tarefas confiável sem overhead operacional, SQS costuma ser o caminho mais racional.

As garantias que definem a corretude

Escolher a ferramenta é metade do trabalho. A outra metade é entender as garantias de entrega e projetar o consumidor para elas.

At-least-once e a obrigação de idempotência

Na prática, a maioria dos sistemas opera com entrega at-least-once: a mensagem chega pelo menos uma vez, podendo chegar duas (se o consumidor processa mas cai antes de confirmar o ack, a mensagem é reentregue). Isso não é um bug: é o preço da confiabilidade.

A consequência é inevitável: o consumidor precisa ser idempotente. Processar a mesma mensagem duas vezes tem que produzir o mesmo resultado que processá-la uma. Técnicas:

• Chave de idempotência: cada mensagem carrega um id único; o consumidor registra os ids já processados e descarta repetições.
• Operações naturalmente idempotentes: SET status = 'pago' é seguro repetir; saldo = saldo + 100 não é.
• Upsert com deduplicação no banco, usando o id da mensagem como chave.

Contar com "exactly-once mágico" é uma armadilha. Mesmo onde existe, ele tem custo e condições; projetar o consumidor idempotente é a defesa que sempre funciona.

Dead letter queue: para onde vão as mensagens que falham

Uma mensagem que falha repetidamente não pode travar a fila nem ser tentada infinitamente. A Dead Letter Queue (DLQ) é uma fila separada para onde a mensagem é desviada após N tentativas. Lá ela é inspecionada, corrigida e reprocessada manualmente, sem bloquear o fluxo saudável. Toda fila de produção séria tem DLQ e retry com backoff exponencial entre tentativas.

Ordenação: mais cara do que parece

Ordem estrita global é custosa e limita paralelismo: se tudo precisa ser processado em sequência, você tem um único consumidor por vez. Por isso a ordenação real é quase sempre parcial: Kafka garante ordem dentro de uma partição; SQS FIFO, dentro de um message group. O truque é escolher a chave de particionamento (por exemplo, id_do_pedido) de forma que os eventos que precisam de ordem caiam na mesma partição, enquanto o resto paraleliza livremente.

Backpressure: quando o produtor corre mais que o consumidor

Se as mensagens entram mais rápido do que saem, a fila cresce sem limite, e um dia estoura memória ou disco. Backpressure é o mecanismo de empurrar essa pressão de volta:

• Escalar consumidores horizontalmente para aumentar a vazão de saída.
• Limitar o produtor (rate limiting) quando a fila passa de um tamanho crítico.
• Monitorar a profundidade da fila (queue depth / consumer lag) como métrica de primeira classe: ela é o termômetro da saúde do sistema. Lag crescente é o alarme mais precoce de que algo está afogando.

Como decidir, sem dogma

Um roteiro pragmático:

• Preciso de uma fila de tarefas confiável e não quero operar infra? SQS.
• Preciso de roteamento rico, prioridades e padrões de trabalho variados? RabbitMQ.
• Preciso que múltiplos serviços derivem coisas do mesmo fluxo de eventos, com reprocessamento e histórico? Kafka.
• Estou em dúvida entre broker e streaming? Pergunte se a mensagem é uma tarefa (some) ou um fato (fica). A resposta escolhe o paradigma antes da ferramenta.

E, acima de tudo: não adote Kafka por moda. Um log distribuído resolve problemas reais de escala e eventos, mas cobra um preço operacional que muitos times pagam sem precisar. Comece pelo problema (desacoplar, absorver picos, distribuir trabalho) e deixe ele apontar a ferramenta.

---

Sua arquitetura está acoplada demais e cai em cascata quando um serviço falha? Na ConstructorTI, desenhamos comunicação assíncrona entre serviços com as garantias certas (idempotência, DLQ, ordenação e backpressure) e escolhemos a ferramenta pelo seu problema, não pela hype. Se você está quebrando um monólito ou domando microsserviços que conversam demais, fale com a nossa engenharia e saia com um blueprint de mensageria sob medida.