Kafka vs RabbitMQ: log de streaming ou broker?
Kafka é um log de eventos distribuído e reproduzível construído para streaming de alto throughput; RabbitMQ é um message broker flexível construído para roteamento e filas de tarefas.
Kafka armazena logs ordenados e particionados que os consumidores leem no próprio offset, permitindo replay, event sourcing e throughput muito alto. RabbitMQ implementa AMQP com exchanges, filas e roteamento flexível, destacando-se em distribuição de tarefas, RPC e topologias de roteamento complexas com acknowledgements por mensagem. Kafka é sobre streams de eventos duráveis; RabbitMQ é sobre entrega inteligente de mensagens.
| Kafka | RabbitMQ | |
|---|---|---|
| Modelo | Log distribuído | Broker (AMQP) |
| Replay | Sim (offsets) | Não (consome e vai) |
| Roteamento | Topic/partition | Rico (exchanges) |
| Throughput | Muito alto | Alto |
| Melhor para | Streaming, event sourcing | Filas de tarefas, roteamento |
Caso de uso e performance
Kafka se adequa a streaming de eventos, pipelines de analytics e sistemas que precisam de replay e múltiplos consumidores independentes. RabbitMQ se adequa a filas de trabalho, request/response e roteamento complexo onde você quer acknowledgements e controle por mensagem. Kafka escala throughput via partitions; RabbitMQ brilha em semântica de entrega flexível.
Em CI
Ambos rodam como service containers, embora o Kafka historicamente precisasse do ZooKeeper (o modo KRaft simplifica isso). Testes de integração devem aguardar a prontidão do broker. Qualquer um roda em runners gerenciados, onde runners mais rápidos encurtam a inicialização do broker e o tempo de teste end-to-end.
O veredito
Streaming de eventos de alto throughput, replay e múltiplos consumidores: Kafka. Roteamento flexível, filas de tarefas e semântica de acknowledgement por mensagem: RabbitMQ. Muitas arquiteturas usam ambos - Kafka para a espinha dorsal de eventos e RabbitMQ para distribuição de tarefas.