Message broker: o que é e quando usar Kafka ou RabbitMQ

Imagine o checkout de uma loja online.

Ao confirmar o pedido, o sistema precisa baixar estoque, emitir nota fiscal, disparar o e-mail de confirmação e acionar o antifraude.

Se o código chama cada um desses serviços em sequência, o tempo de resposta vira a soma de todos eles.

Se o serviço de nota fiscal cair, o pedido inteiro falha.

Um message broker existe para cortar esse nó. ## O que um message broker faz, na prática Message broker é um software intermediário que recebe mensagens de aplicações produtoras e as entrega a aplicações consumidoras.

O produtor publica um evento e segue em frente, sem saber quem vai ler aquilo nem se o consumidor está online naquele instante.

O consumidor processa no ritmo que consegue.

Esse desacoplamento resolve três problemas de uma vez.

O primeiro é disponibilidade: se o serviço de e-mail estiver fora, as mensagens ficam guardadas e são entregues depois.

O segundo é picos de carga: em vez de dimensionar todo o sistema para o volume máximo, a fila absorve a onda e os consumidores trabalham em velocidade constante.

O terceiro é acoplamento de código: adicionar um novo consumidor para o mesmo evento não exige mexer no produtor.

O erro mais comum é tratar qualquer broker como equivalente.

Por baixo do nome genérico existem dois modelos bem diferentes, e a escolha entre eles define o que sua arquitetura consegue fazer. ## Fila com consumo único: o modelo do RabbitMQ O RabbitMQ trabalha sobre o protocolo AMQP e segue a lógica clássica de fila.

A mensagem entra, um consumidor a retira, ela é removida.

Se houver cinco consumidores na mesma fila, cada mensagem vai para apenas um deles, o que distribui carga automaticamente.

O ponto forte está no roteamento.

O RabbitMQ usa exchanges para decidir para qual fila uma mensagem vai, com regras por chave, por padrão de texto ou por cabeçalho.

Isso permite montar fluxos como fila de prioridade, fila de mensagens mortas para o que falhou e confirmação de entrega por parte do consumidor.

Esse desenho encaixa em tarefas que precisam rodar uma única vez: processar um pagamento, gerar um PDF, enviar um SMS.

Se a tarefa é um comando endereçado a alguém, a fila é o encaixe natural. ## Log distribuído: o modelo do Kafka O Apache Kafka nasceu no LinkedIn e parte de outra ideia.

Em vez de apagar a mensagem após a leitura, ele grava tudo em um log particionado e append-only.

Cada consumidor guarda sua própria posição, o offset, e lê no seu ritmo.

Nada é removido na leitura.

A consequência prática é que dez consumidores diferentes podem ler o mesmo evento, cada um para um fim.

O time de recomendação, o de fraude e o de analytics consomem o mesmo fluxo de cliques sem interferir um no outro.

E como o log fica retido por um período configurável, dá para reprocessar dados antigos, refazer um cálculo errado ou subir um serviço novo que precisa reconstruir o histórico.

O Kafka foi feito para volume alto e fluxo contínuo.

É a peça típica de pipelines de dados, ingestão de eventos e integração entre sistemas que geram informação sem parar. ## Quando cada um entra Vá de Kafka quando o mesmo dado interessa a vários times, quando você precisa reler eventos passados ou quando o volume é o problema principal.

Um sistema de rastreamento de entregas que alimenta painel operacional, modelo de previsão e alerta ao cliente é caso de log distribuído.

Vá de RabbitMQ quando cada mensagem tem um destino específico, quando o roteamento é complexo ou quando a tarefa precisa de confirmação individual de processamento.

Um fluxo de emissão de documentos, com retentativa e fila de falhas por tipo de erro, se encaixa melhor aqui.

Existe ainda o caminho gerenciado.

O Amazon SQS entrega filas prontas dentro da AWS, sem servidor para operar, e costuma entrar na conversa quando o time não quer manter cluster próprio.

A contrapartida é menos controle sobre roteamento e sobre retenção. ## O que decidir antes de subir o cluster Três perguntas resolvem boa parte da dúvida.

Primeira: mais de um consumidor precisa ler o mesmo evento?

Se sim, o modelo de log leva vantagem.

Segunda: a ordem das mensagens importa para o negócio?

Kafka garante ordem dentro de uma partição, e isso precisa entrar na conta.

Terceira: quem vai operar isso?

Kafka e RabbitMQ são sistemas distribuídos, com réplicas, monitoramento e ajuste de retenção.

Sem alguém responsável, qualquer um dos dois vira dívida.

Vale considerar também o custo de errar.

Migrar de um modelo de fila para um modelo de log não é trocar biblioteca: exige repensar como os consumidores guardam estado e como o reprocessamento funciona.

Por isso a decisão costuma valer mais tempo de análise do que a implementação em si. ## Perguntas que aparecem com frequência **Dá para usar os dois no mesmo sistema?** Dá, e é comum.

Kafka costuma ficar no transporte de eventos entre serviços, enquanto RabbitMQ cuida de tarefas internas de um serviço específico, onde o roteamento por fila resolve melhor. **Message broker é a mesma coisa que fila?** Não.

Fila é um dos modelos que um broker pode oferecer.

O Kafka, por exemplo, não funciona como fila tradicional, já que a mensagem não é apagada na leitura. **Preciso de broker desde o começo?** Não necessariamente.

Enquanto a comunicação é simples e há poucos serviços, chamadas diretas funcionam.

O broker passa a se pagar quando o número de integrações cresce e a falha de um serviço começa a derrubar outros.