Azure Service Bus vs RabbitMQ
Azure Service Bus and RabbitMQ both deliver messages between services, but in different ways: Service Bus is a managed Azure service, with queues and topics ready to use; RabbitMQ is an open source broker you run (or buy as a managed service), with flexible routing. This comparison shows where each one differs day to day.
Service Bus vs RabbitMQ, side by side
| Topic | Azure Service Bus | RabbitMQ |
|---|---|---|
| Model | A namespace with queues and topics; each topic delivers to subscriptions, with filters | Exchanges (direct, topic, fanout, headers) that route to queues through bindings |
| Protocol | AMQP 1.0 and HTTPS | AMQP 0-9-1, plus AMQP 1.0, MQTT and STOMP through plugins |
| DLQ | Every queue and subscription already has a DLQ ($deadletterqueue), with the reason in DeadLetterReason | Not built in: set up a dead letter exchange (x-dead-letter-exchange) through a policy or a queue argument |
| When a message is dead-lettered | It passed MaxDeliveryCount (default 10), expired with dead-lettering on, hit a filter error, or the application sent it there | Rejected without requeue, expired (TTL), overflowed the queue length or, on quorum queues, passed the delivery-limit; the reason goes in the x-death header |
| Sessions and ordering | Sessions (SessionId): guaranteed order and one consumer per session | No sessions; order per queue, and single active consumer for one consumer at a time |
| Peek (read without consuming) | Native: reads without locking and without changing the delivery count | Not available on classic and quorum queues: reading through the management API puts the message back, flagged as redelivered |
| Purge | Emptying means receiving and deleting the messages; scheduled ones and those locked by a consumer stay | A native, immediate operation (queue.purge) |
| Scheduling and duplicates | Scheduled messages, and duplicate detection on the Standard and Premium tiers | Through plugins or in the application |
| Operations | Managed by Azure: no servers, upgrades or cluster to look after | You handle versions, cluster, disk, memory and alarms, or pay for a managed service |
| Network | Public endpoint with IP rules; private endpoints on Premium | Wherever you install it: a VM, Kubernetes or a managed provider |
| Cost model | By tier: Basic and Standard charge per operation (Standard has a base fee); Premium, per messaging unit per hour | The software is free; the cost is infrastructure and operating time, or the provider’s plan |
When Azure Service Bus makes more sense
- Your systems already run on Azure and nobody wants to operate a broker.
- You need sessions (ordering by key), scheduled messages or duplicate detection without writing them into the application.
- Every queue must have a DLQ, without depending on someone remembering to set it up.
When RabbitMQ makes more sense
- Multi-cloud or on-premises, or the broker must run in the same Kubernetes cluster as the application.
- Flexible routing: one message to several queues by key pattern, fanout or headers.
- You want to control cost with your own infrastructure and already have someone to run it.
- Clients on other protocols, such as MQTT.
DLQ on Service Bus and RabbitMQ: what changes in practice
On Service Bus, the DLQ is a subqueue of each entity and each message carries the reason. A message that fails more times than MaxDeliveryCount goes there on its own.
On RabbitMQ, the DLQ is an ordinary queue, bound to the dead letter exchange. If nobody set up the policy, a rejected message is dropped. Check the policy before trusting that a DLQ exists.
How Kubepier shows both
In Kubepier, each client’s RabbitMQ and Azure Service Bus open on the same queue dashboard, on the web and on desktop: every queue on one screen, with the DLQ next to it, the same alerts (DLQ, DLQ growing, DLQ spike, no consumption and high backlog), message peek and purge with the typed name.
Each one’s differences show where they exist: on RabbitMQ, in and out per minute from the broker counters and the DLQ paired by dead letter routing key or name suffix; on Service Bus, the net change per minute (the API does not split in and out), scheduled and transfer messages, a peek that locks nothing and a purge in batches of 250 that leaves scheduled and locked messages.