Você já leu em algum lugar que message queue e event bus são a mesma coisa, só com nomes diferentes. Não são. A confusão é comum, porque ambos lidam com eventos, mas resolvem problemas distintos. Um entrega trabalho para ser processado. O outro anuncia que algo aconteceu para quem quiser ouvir. A escolha errada gera sistema lento ou mensagem perdida. Este texto separa os dois critério por critério, com um veredito claro no final.
A diferença central: message queue usa modelo ponto a ponto, onde cada mensagem tem um único consumidor. Event bus usa publish/subscribe, onde o mesmo evento chega a vários assinantes ao mesmo tempo. Em termos práticos, fila é para tarefa, barramento é para notícia. Se o seu caso exige processamento garantido, fila. Se exige reação em tempo real de vários serviços, barramento.
Critério 1: modelo de entrega
Message queue entrega cada mensagem a exatamente um consumidor. Se dois workers estão escutando, apenas um processa. Isso garante que uma tarefa não seja feita duas vezes. Event bus, por outro lado, publica o evento e todos os assinantes recebem uma cópia. No barramento, não há disputa: cada serviço reage de forma independente. Um exemplo concreto: em um e-commerce, a fila processa pagamento uma única vez. O event bus notifica estoque, e-mail e analytics simultaneamente sobre o pedido.
Critério 2: garantia de processamento
Message queue é mais forte em garantia. O consumidor confirma o processamento, e se falhar, a mensagem volta para a fila. Isso é essencial para operações críticas, como transferência bancária. Event bus entrega o evento, mas não confirma se o assinante processou com sucesso. Em muitos barramentos, o evento é descartado após a entrega. Se o assinante estiver fora do ar, ele perde o evento. Para notificações de baixa criticidade, tudo bem. Para dados financeiros, não.
Critério 3: acoplamento entre serviços
Aqui o event bus leva vantagem. Com publish/subscribe, o produtor não conhece os consumidores. Ele apenas publica o evento. Novos serviços podem assinar sem alterar o produtor. Isso reduz o acoplamento e facilita evolução. Na message queue, o produtor define a fila e o consumidor, embora desacoplado no tempo, ainda depende do nome da fila e do formato da mensagem. O barramento é mais flexível para sistemas que crescem com novos módulos.
Critério 4: desempenho e latência
Event bus entrega eventos em tempo real, com latência baixa, pois o evento é empurrado ao assinante assim que publicado. Message queue também tem latência baixa, mas o consumidor precisa puxar ou ser notificado, e o processamento é sequencial por mensagem. Em cenários de alto volume, a fila pode se tornar gargalo, enquanto o barramento escala horizontalmente com múltiplos assinantes. Porém, o barramento não garante ordem de processamento entre assinantes distintos, o que pode ser problema em certos fluxos.
Critério 5: tolerância a falhas
Message queue é superior em tolerância a falhas. Mensagens persistidas em disco sobrevivem a reinício do broker. Se o consumidor cair, a mensagem fica aguardando. Event bus, em sua forma mais simples, é volátil. Eventos não persistidos se perdem se o broker reiniciar. Existem barramentos com persistência, mas o padrão é mais fraco. Para sistemas onde perder evento é inaceitável, fila é a escolha. Para telemetria ou logs, barramento basta.
Tabela comparativa rápida
| Critério | Message Queue | Event Bus | | --- | --- | --- | | Modelo | Ponto a ponto | Publish/subscribe | | Consumidores | Um por mensagem | Múltiplos assinantes | | Garantia de entrega | Alta, com confirmação | Baixa, sem confirmação | | Acoplamento | Médio | Baixo | | Latência | Baixa, mas sequencial | Baixa, em tempo real | | Tolerância a falhas | Alta, com persistência | Baixa, volátil | | Uso típico | Tarefas assíncronas | Notificações broadcast |
Critério 6: facilidade de implementação
Message queue exige mais cuidado. Você precisa configurar dead letter queue, timeouts e retries. É mais código para acertar. Event bus é mais simples de começar: publica e assina, e pronto. Mas a simplicidade esconde armadilhas. Sem garantia de entrega, você pode ter eventos perdidos silenciosamente. Para projetos pequenos, barramento é rápido. Para sistemas críticos, fila dá mais segurança, mesmo com mais trabalho.
Critério 7: custo e infraestrutura
Ambos exigem um broker, mas o custo varia. Filas costumam demandar mais armazenamento persistente e configuração de replicação. Barramentos podem ser mais leves, especialmente se você usa soluções gerenciadas. O custo real depende do volume e da necessidade de durabilidade. Se você precisa de replay de eventos, fila sai mais cara. Se só precisa de notificação efêmera, barramento é mais econômico. Não existe regra fixa, mas a tendência é clara.
Veredito: quando usar cada um
Para quem busca processamento garantido de tarefas, com confirmação e persistência, a message queue é a escolha. Use para jobs, pagamentos, envio de e-mails e qualquer operação que não pode falhar. Para quem busca distribuir eventos em tempo real para vários serviços desacoplados, o event bus é melhor. Use para notificações, atualização de cache, telemetria e reações em tempo real. Em sistemas complexos, os dois coexistem: fila processa o pedido, barramento avisa o resto.
Como próximo passo prático, desenhe o seu fluxo e identifique se cada etapa é uma tarefa ou uma notícia. Se for tarefa, fila. Se for notícia, barramento. Faça um teste com um broker simples, como RabbitMQ para fila e Kafka para eventos, e meça a diferença na prática.
Perguntas frequentes
Message queue e event bus são a mesma coisa?
Não. Message queue entrega cada mensagem a um único consumidor, com garantia de processamento. Event bus distribui o mesmo evento a múltiplos assinantes, sem garantia de confirmação. São padrões de arquitetura diferentes para problemas diferentes.
Kafka é message queue ou event bus?
Kafka é um sistema de streaming que combina características dos dois. Ele permite múltiplos consumidores por partição, como barramento, mas com persistência e replay, como fila. Na prática, é usado como event bus em arquiteturas event-driven.
Quando usar message queue em vez de event bus?
Use message queue quando cada mensagem precisa ser processada exatamente uma vez, como em processamento de pagamento ou envio de e-mail. A fila garante que a tarefa não se perca e não seja duplicada. Event bus não oferece essa garantia.
Event bus perde eventos se o assinante estiver offline?
Em barramentos simples, sim. O evento é publicado e descartado se não houver assinante ativo. Alguns barramentos com persistência, como Kafka, retêm eventos e permitem reprocessamento. Verifique a configuração do seu broker antes de assumir durabilidade.
Posso usar ambos na mesma arquitetura?
Sim, é comum. Use message queue para processamento crítico e event bus para notificações em tempo real. Por exemplo, uma fila processa o pedido e um barramento notifica estoque e e-mail. Essa combinação equilibra garantia e agilidade.