RabbitMQ vs Kafka vs Pulsar
Comparação entre as três principais tecnologias de mensageria/streaming distribuído.
🐇 RabbitMQ — Message Broker
Tipo: Broker de mensagens tradicional (push-based)
Como funciona
- Producers (Web Apps, Mobile, IoT) publicam mensagens para o Broker
- O Broker possui um sistema de Exchange que roteia as mensagens por meio de Binding Rules para as Queues
- Os consumers recebem as mensagens via push (competing consumers)
Tipos de Exchange
| Tipo | Descrição |
|---|---|
| Direct | Roteia para uma fila específica via Binding Key |
| Topic | Roteia com base em padrões (Routing Pattern) |
| Fanout | Envia para todas as filas vinculadas ao mesmo tempo |
Características principais
- Foco em roteamento flexível de mensagens
- Modelo push: o broker empurra mensagens para os consumers
- Ideal para workflows, tarefas assíncronas e comunicação entre serviços
- Mensagens são geralmente consumidas e removidas da fila
⚡ Kafka — Event Streaming
Tipo: Plataforma de streaming de eventos distribuída (pull-based)
Como funciona
- Producers fazem append de eventos no líder da partição dentro de um Kafka Cluster
- O cluster é composto por múltiplos Brokers, cada um com Partitions (Leader + Replicas)
- Os consumers fazem poll (requisição ativa) baseado em offset
Arquitetura de cluster
- Cada partição tem um Leader e Replicas distribuídas entre os brokers
- A replicação garante alta disponibilidade e tolerância a falhas
- O offset permite que consumers leiam e releiam eventos no tempo
Características principais
- Foco em throughput altíssimo e retenção de eventos
- Modelo pull/offset-based: consumers controlam o que já leram
- Ideal para pipelines de dados, event sourcing, analytics em tempo real
- Mensagens ficam armazenadas por um período configurável
🌊 Pulsar — All-in-One
Tipo: Sistema unificado de mensageria e streaming (cursor-based)
Como funciona
- Producers publicam mensagens para o Broker Pulsar, que possui partições internas
- As mensagens são armazenadas de forma separada no BookKeeper (camada de armazenamento)
- O BookKeeper organiza os dados em Ledgers (segmentos) distribuídos entre Bookies
- Consumers acessam via Subscription com modelo cursor-based
Arquitetura separada (compute vs storage)
- Brokers: responsáveis apenas pelo processamento
- BookKeeper: responsável apenas pelo armazenamento
- Essa separação permite escalar cada camada de forma independente
Características principais
- Combina o melhor do RabbitMQ (filas, subscriptions) com o do Kafka (streaming, retenção)
- Modelo cursor-based: cada subscription mantém seu próprio cursor de leitura
- Ideal para cenários que exigem flexibilidade tanto em mensageria quanto em streaming
- Suporte nativo a multi-tenancy e geo-replicação
📊 Comparativo Rápido
| Critério | RabbitMQ | Kafka | Pulsar |
|---|---|---|---|
| Modelo | Push | Pull (offset) | Pull (cursor) |
| Armazenamento | Temporário (na fila) | Durável (log) | Durável (BookKeeper) |
| Caso de uso principal | Task queues, workflows | Event streaming, pipelines | All-in-one (filas + streaming) |
| Throughput | Médio | Muito alto | Alto |
| Complexidade | Baixa | Média | Alta |
| Roteamento | Flexível (Exchange) | Por partição/tópico | Por tópico/partição |
Fonte: ByteByteGo