Azure Service Bus vs RabbitMQ
Azure Service Bus e RabbitMQ entregam mensagens entre serviços, mas de jeitos diferentes: o Service Bus é um serviço gerenciado da Azure, com filas e tópicos prontos; o RabbitMQ é um broker de código aberto que você roda (ou contrata gerenciado), com roteamento flexível. Este comparativo mostra onde cada um difere no dia a dia.
Service Bus vs RabbitMQ, lado a lado
| Tema | Azure Service Bus | RabbitMQ |
|---|---|---|
| Modelo | Namespace com filas e tópicos; cada tópico entrega para assinaturas, com filtros | Exchanges (direct, topic, fanout, headers) que roteiam para filas pelos bindings |
| Protocolo | AMQP 1.0 e HTTPS | AMQP 0-9-1, e por plugins AMQP 1.0, MQTT e STOMP |
| DLQ | Toda fila e assinatura já tem uma DLQ ($deadletterqueue), com motivo em DeadLetterReason | Não vem pronta: configure uma dead letter exchange (x-dead-letter-exchange) por política ou argumento da fila |
| Quando vai para a DLQ | Passou do MaxDeliveryCount (padrão 10), expirou com dead-lettering ligado, erro de filtro, ou a aplicação mandou | Rejeitada sem requeue, expirou (TTL), estourou o tamanho da fila ou, em quorum queues, passou do delivery-limit; o motivo fica no header x-death |
| Sessões e ordem | Sessões (SessionId): ordem garantida e um consumidor por sessão | Sem sessões; ordem por fila, e single active consumer para um consumidor por vez |
| Peek (ler sem consumir) | Nativo: lê sem travar e sem mudar a contagem de entregas | Não existe em filas clássicas e quorum: a leitura pela API de gerenciamento devolve a mensagem para a fila, marcada como reentregue |
| Purge | Esvaziar é receber e apagar as mensagens; agendadas e travadas por um consumidor ficam | Operação nativa e imediata (queue.purge) |
| Agendamento e duplicidade | Mensagens agendadas, e detecção de duplicadas nos tiers Standard e Premium | Por plugins ou na aplicação |
| Operação | Gerenciado pela Azure: sem servidor, atualização ou cluster para cuidar | Você cuida de versão, cluster, disco, memória e alarmes, ou paga um serviço gerenciado |
| Rede | Endpoint público com regras de IP; private endpoint no Premium | Onde você instalar: VM, Kubernetes ou provedor gerenciado |
| Modelo de custo | Por tier: Basic e Standard cobram por operação (o Standard tem uma taxa base); Premium, por unidade de mensagens por hora | O software é grátis; o custo é a infraestrutura e o tempo de operação, ou o plano do provedor |
Quando o Azure Service Bus faz mais sentido
- Os sistemas já rodam na Azure e ninguém quer operar broker.
- Você precisa de sessões (ordem por chave), mensagens agendadas ou detecção de duplicadas sem escrever isso na aplicação.
- A DLQ precisa existir em toda fila, sem depender de alguém lembrar de configurar.
Quando o RabbitMQ faz mais sentido
- Multi-nuvem ou on-premises, ou o broker precisa rodar no mesmo cluster Kubernetes da aplicação.
- Roteamento flexível: uma mensagem para várias filas por padrão de chave, fanout, headers.
- Você quer controlar o custo com a sua infraestrutura e já tem quem opere.
- Clientes em outros protocolos, como MQTT.
DLQ no Service Bus e no RabbitMQ: o que muda na prática
No Service Bus, a DLQ é uma subfila de cada entidade e cada mensagem leva o motivo. Uma mensagem que falha mais vezes que o MaxDeliveryCount vai para lá sozinha.
No RabbitMQ, a DLQ é uma fila comum, ligada à dead letter exchange. Se ninguém configurou a política, a mensagem rejeitada é descartada. Confira a política antes de confiar que existe DLQ.
Como o Kubepier mostra os dois
No Kubepier, o RabbitMQ e o Azure Service Bus de cada cliente abrem no mesmo painel de filas, na web e no desktop: as filas numa tela, com a DLQ ao lado, os mesmos alertas (DLQ, DLQ crescendo, pico na DLQ, sem consumo e backlog alto), espiar mensagens e purgar com o nome digitado.
As diferenças de cada um aparecem onde existem: no RabbitMQ, entrada e saída por minuto pelos contadores do broker e a DLQ pareada pela dead letter routing key ou pelo sufixo do nome; no Service Bus, a variação líquida por minuto (a API não separa entrada e saída), mensagens agendadas e em transferência, peek que não trava nada e purge em lotes de 250, que deixa as agendadas e as travadas.