Azure Service Bus vs Event Hubs: A 2026 Decision Guide
Pick the wrong one of these two and you will feel it in production — usually around the time a downstream consumer fails and you discover the platform you chose has no concept of a poison message, or that you are paying for ten partitions to move a few hundred commands an hour. The azure service bus vs event hub decision is not a feature beauty contest; it is a decision about what kind of data you are moving and what guarantees you owe the rest of the system. Service Bus is enterprise messaging built for discrete units of work that must be processed reliably and often in order. Event Hubs is an event-streaming pipeline built to absorb millions of telemetry events and let many independent readers replay them at their own pace. They look superficially similar — both accept AMQP, both sit between producers and consumers — but their semantics, failure behaviour, and cost curves diverge sharply once you are past a toy prototype.
What this covers: the architectural distinction, ordering and dead-lettering semantics, throughput and cost models, a per-workload decision matrix, the gotchas that bite teams in production, and when to deploy both together.
Context and Background
Azure exposes three first-party messaging services, and conflating them is the single most common source of mis-architected event-driven systems. Service Bus is the brokered message queue: producers send a message, the broker stores it durably, and one consumer eventually takes ownership, processes it, and settles it. The defining trait is that a message is consumed — once a worker completes it, it is gone from the queue. This is the right model for commands and work items: “charge this card,” “render this invoice,” “provision this tenant.” Each must happen once, reliably, with a clear path for what to do when it cannot.
Event Hubs is the opposite shape. It is an append-only, partitioned log — closer to Apache Kafka than to a traditional queue. Producers append events; the events are retained for a configured window regardless of who has read them; and consumers track their own position with offsets and checkpoints. Nothing is “consumed” in the Service Bus sense. Ten different consumer groups can read the same firehose of clickstream or IoT telemetry independently, and a new consumer can rewind to replay history. This is the model for high-volume ingestion and stream processing, where the value is in the aggregate flow rather than in any single message.
The third service, Event Grid, rounds out the picture and is worth naming so you do not reach for the wrong tool. Event Grid is a reactive, push-based event router — it dispatches discrete notifications (“a blob was created,” “a resource was deployed”) to subscribers via HTTP webhooks or handlers, with no durable log and no high-throughput streaming guarantees. If your need is “react to this state change,” Event Grid often beats both of the services this guide compares. Microsoft’s own choose between Azure messaging services guidance frames the trio as discrete events (Event Grid), application messages (Service Bus), and event streams (Event Hubs) — a framing worth internalising before you write any code. For the broader patterns these services slot into, see our deep dive on async processing architecture patterns, which treats queues and streams as composable building blocks rather than competitors.
Architecture and Semantics Compared
Figure 1: Service Bus delivers each message to one competing consumer that settles it, while Event Hubs appends events to a partitioned log that many reader groups consume independently by tracking their own offsets.
The short answer: choose Service Bus when you are moving discrete work that must be processed reliably, often in order, with first-class handling for messages that fail — queues, topics, sessions, and dead-letter queues. Choose Event Hubs when you are ingesting a high-volume stream of events that multiple independent consumers read and replay at their own pace — partitions, consumer groups, and offset checkpointing. The first is a broker; the second is a log.
Figure 1 shows the structural difference. On the Service Bus side, a producer sends a command into a queue or topic, and competing consumers pull from it; whichever worker grabs the message owns it until it settles the message by completing or abandoning it. On the Event Hubs side, producers append events to a partitioned log, and each reader group maintains its own offset, so the same event can be read by analytics, archival, and alerting pipelines without any of them affecting the others.
Service Bus: queues, topics, sessions, and dead-letters
A Service Bus queue is point-to-point: many producers, many consumers, but each message is delivered to exactly one consumer under the competing-consumers pattern. A topic adds publish-subscribe: a message published to a topic is copied into every subscription attached to it, and each subscription is itself a queue with its own competing consumers and its own SQL-like or correlation filters. This is how you fan one logical event out to billing, shipping, and audit without coupling the producer to any of them.
When ordering matters, Service Bus offers sessions. A session groups related messages by a session ID and locks the whole group to a single consumer, giving you first-in-first-out (FIFO) processing within that session while still scaling across sessions. Without sessions, Service Bus does not promise strict global ordering under concurrent consumers — a critical detail teams overlook.
The feature that most decisively separates Service Bus from Event Hubs is the dead-letter queue (DLQ). Every queue and subscription has a system sub-queue where messages land when they exceed the max delivery count, expire, or fail filter evaluation. This gives you a durable, inspectable parking lot for poison messages — no custom code, no data loss. Service Bus also supports scheduled delivery (publish now, become visible later), deferred messages (set aside for later retrieval by sequence number), and atomic transactions that span multiple send and complete operations. None of these have a native equivalent in Event Hubs.
The lock mechanism underneath all of this is worth understanding because it shapes how you write consumers. When a worker receives a message in peek-lock mode (the default for reliable processing), the broker hands over the message but keeps it invisible to other consumers for the duration of a lock — typically up to a few minutes, renewable. The worker then either calls complete (the message is permanently removed), abandon (the lock is released and the message becomes immediately available again, incrementing the delivery count), dead-letter (it moves to the DLQ explicitly), or defer (it is set aside). If the worker crashes or the lock simply expires before it settles, the message reappears for redelivery — which is exactly why at-least-once is the floor and idempotency is mandatory. The alternative receive-and-delete mode removes the message the instant it is read, trading durability for throughput; use it only when losing the occasional message is acceptable. Getting lock duration wrong is a classic foot-gun: set it too short for a long-running handler and the message gets redelivered mid-processing, producing duplicate work; set it too long and a crashed worker holds a message hostage for minutes before anyone else can retry it.
The max delivery count is the other lever that determines DLQ behaviour. Each abandon or lock expiry bumps a counter; when it crosses the configured threshold (10 by default), the broker stops retrying and dead-letters the message automatically. This converts an unbounded retry storm — the kind that hammers a failing downstream and never makes progress — into a bounded, observable failure: after N attempts, the message is parked, an operator (or an automated DLQ drain) inspects it, and the main queue keeps flowing. That single built-in behaviour is the reason teams reach for Service Bus when correctness under failure matters more than raw speed.
Event Hubs: partitions, consumer groups, and checkpoints
Event Hubs scales through partitions. Each event carries an optional partition key; events with the same key always land in the same partition and are therefore ordered relative to each other. Partition count is the unit of parallelism — you cannot have more concurrently-active readers in a consumer group than you have partitions, and partition count is largely fixed at creation, so sizing it is an early, consequential decision.
A consumer group is an independent view over the entire event hub. Each group reads all partitions and tracks its own progress, which is what lets the same stream feed many pipelines. Within a group, the recommended model gives one active reader ownership of each partition. Progress is recorded by checkpointing — periodically writing the last-processed offset (typically to Azure Blob Storage). On restart or rebalance, readers resume from the last checkpoint. This is the mechanism behind replay: because events are retained independently of consumption, a consumer can reset its offset and reprocess history.
Event Hubs also offers Capture, which automatically lands the raw stream into Blob Storage or Data Lake as Avro for cheap long-term retention and batch reprocessing, and a Kafka endpoint that makes an event hub speak the Kafka protocol — existing Kafka producers and consumers connect with a connection-string change, no broker to run. Microsoft’s Event Hubs documentation is the authoritative reference for these capabilities and their current limits.
The reader-side machinery is where Event Hubs differs most from a queue, and it pays to be precise about it. In practice you do not poll partitions yourself; you use a processor library — the Event Processor in the modern Azure SDKs — that does three jobs for you: it discovers the partitions, distributes ownership of those partitions across whatever instances of your application are running, and persists checkpoints to a durable store. When you scale your consumer application from two instances to five, the processor rebalances — it reassigns partition ownership so the load spreads, and each newly-assigned instance resumes from the last checkpoint that the previous owner wrote. This is elegant when it works and treacherous when checkpoints are sloppy: a rebalance that lands a partition on a new owner will replay every event since the last checkpoint, so a consumer that checkpoints rarely will reprocess a large burst on every scale event. The retention window is the other half of the replay story. Standard tier retains events for up to a configured number of days; if a consumer falls behind the retention horizon, the oldest events age out and are gone, and that consumer has a permanent gap. Sizing retention is therefore a function of how far behind your slowest consumer is allowed to fall during an outage, not an arbitrary default.
Delivery and ordering semantics
Both services deliver with at-least-once semantics by default, so idempotent consumers are non-negotiable on either platform. The difference is where ordering lives. Service Bus orders within a session (or within a single non-partitioned queue read serially); Event Hubs orders within a partition. Neither guarantees global total ordering across the whole entity under parallel consumption — that is a property you trade away for throughput. If your design assumes strict global order, you are designing against the grain of both services and should narrow the ordering requirement to a key (a session ID or a partition key) before going further. The Service Bus documentation spells out the session and FIFO mechanics precisely.
There is a subtler asymmetry in how the two recover ordering after a failure. In Service Bus with sessions, a crashed consumer releases its session lock and another consumer picks up the same session and continues in order from the next unsettled message — ordering survives the failover because the session, not the consumer, owns the sequence. In Event Hubs, ordering is a property of the partition, and the offset is the only bookmark; a consumer that fails over resumes at the checkpointed offset, which means any events it had processed but not yet checkpointed get replayed in order. So both preserve order across failover, but they differ in what gets repeated: Service Bus repeats only unsettled messages, while Event Hubs repeats everything since the last checkpoint. That distinction drives how aggressively you checkpoint and how strictly idempotent each consumer must be. The practical rule: on Service Bus, settle promptly and lean on the broker; on Event Hubs, checkpoint at a cadence you can afford to replay, and make replay harmless by design.
Throughput, Cost, and Choosing
Figure 2: A Service Bus topic copies each published message into every subscription, where independent filters and competing-consumer workers process it, and failures route to a dead-letter queue.
Throughput is where the two services live on different planets. Service Bus is sized for thousands of messages per second per entity — high for application messaging, but it is not a firehose. Event Hubs is sized for millions of events per second through partition-parallel ingestion. If you find yourself trying to push high-frequency telemetry through Service Bus, you will hit throttling and cost walls; if you are pushing a few hundred commands an hour through a ten-partition Event Hub, you are over-engineering and over-paying. Figure 2 shows the Service Bus fan-out path, and Figure 3 (below) shows the Event Hubs partition-parallel path — the visual contrast captures why one is a broker and the other a pipe.
Figure 3: Producers route events to partitions by key; a consumer group reads all partitions with one owning reader each, and checkpoints offsets to durable storage so it can resume or replay.
The cost models differ in kind, not just amount. Service Bus bills by tier and operations: the Standard tier is shared-capacity and priced per million operations with a base fee, while the Premium tier provisions dedicated messaging units for predictable latency, isolation, and features like larger messages. Event Hubs bills by throughput units (the Standard tier’s unit of ingress/egress capacity, roughly 1 MB/s in or 2 MB/s out per unit) or processing units in the Premium tier, plus a Dedicated tier for the largest workloads. Treat every specific price or limit here as moving — Azure revises tiers, quotas, and rates regularly, so confirm against the live pricing page and quota docs before you commit a budget.
| Criterion | Service Bus | Event Hubs |
|---|---|---|
| Workload type | Discrete commands and work items | High-volume event/telemetry streams |
| Ordering | FIFO within a session | Ordered within a partition |
| Throughput | Thousands of msgs/sec per entity | Millions of events/sec via partitions |
| Retention / replay | Until consumed (then gone) | Time-windowed; replay via offsets |
| Consumer model | Competing consumers (consumed once) | Consumer groups (independent, replayable) |
| Protocols | AMQP 1.0, HTTPS | AMQP, HTTPS, Kafka endpoint |
| Dead-lettering | Native DLQ per queue/subscription | None native (handle downstream) |
| Cost model | Tier + operations / messaging units | Throughput / processing units |
The two are not mutually exclusive — the most robust event-driven systems use both together. A common pattern: Event Hubs ingests the raw high-volume stream (clicks, sensor readings, transactions), a stream processor enriches and filters it, and the small set of resulting actionable items — refunds to issue, alerts to dispatch, orders to fulfil — are handed to Service Bus queues where competing workers process them reliably with dead-lettering and retries. The stream absorbs volume; the broker guarantees work. Our analysis of real-time payment infrastructure shows exactly this division of labour, where an ingestion stream feeds a reliable settlement-work pipeline.
On tier selection: reach for Service Bus Premium when you need predictable latency, network isolation (private endpoints), or large messages, and Standard when cost matters more than isolation for a modest workload. For Event Hubs, start with a small number of throughput units with auto-inflate enabled, move to processing units (Premium) for better isolation and per-namespace predictability, and reserve Dedicated for sustained multi-gigabyte-per-second workloads.
It helps to reason about the cost crossover rather than the sticker price, because the sticker price moves but the shape of the curve does not. Service Bus Standard’s per-operation billing is friendly at low volume — a handful of operations per message (send, receive, complete) at fractions of a cent per million means a workload of a few hundred thousand messages a day costs very little. But because every send, receive, and settle is a billable operation, that model climbs steeply as volume grows, and somewhere in the high-throughput regime a fixed-capacity tier (Premium messaging units, or Event Hubs throughput units) becomes cheaper and more predictable than paying per operation. Event Hubs inverts the economics: you provision capacity (throughput units or processing units) and pay for it whether or not you saturate it, so it is comparatively expensive for a trickle and very cheap per event at scale. The decision rule that falls out of this is not “which is cheaper” in the abstract but “where does my sustained volume sit relative to the crossover” — low and bursty favours Service Bus Standard’s pay-per-use, high and steady favours a provisioned-capacity tier on either service. Model your real ingress and egress volumes against current published rates before committing; the qualitative shape here is durable, the exact numbers are not.
Trade-offs, Gotchas, and What Goes Wrong
Figure 4: Start from the kind of data you are moving — discrete work routes toward Service Bus, high-volume events toward Event Hubs, pure state-change routing toward Event Grid, and many pipelines use a stream feeding a work queue.
The first and most painful mistake is using Event Hubs where you need per-message dead-lettering. Event Hubs has no native DLQ — if an event is malformed and your consumer cannot process it, you must build your own poison-handling: route the bad event to a separate hub or storage, or accept that a bad offset can stall a partition. Teams migrating from a queue mindset assume the safety net is there; it is not.
Second, partition-key skew creates hot partitions. If your partition key is low-cardinality or unevenly distributed — say, hashing on a country code where 80% of traffic is one country — one partition saturates while others idle, and your effective throughput collapses to a single partition’s capacity. Choose a high-cardinality, evenly-distributed key, or let Event Hubs round-robin when ordering does not matter.
Third, checkpoint mismanagement causes silent data loss or duplication. Checkpoint too rarely and a crash reprocesses a large window (manageable with idempotency); checkpoint before processing completes and a crash skips events permanently. Checkpoint after successful processing, and design every consumer to be idempotent because redelivery is guaranteed.
A fourth trap is assuming a topic subscription gives you replay. It does not. A Service Bus subscription is still a queue — once a subscription’s consumer completes a message, it is gone from that subscription, and a new consumer cannot rewind to read history. Teams sometimes model an audit or analytics pipeline as “just another subscription” and then discover they cannot reprocess last week’s events after a bug fix. If reprocessing history is a requirement, that pipeline wants an event log (Event Hubs), or you must persist the stream yourself. The publish-subscribe surface of a topic looks like a stream but behaves like N independent queues.
Finally, the Service Bus failure mode is the inverse: throughput ceilings. Service Bus is not built for firehose ingestion. Push high-frequency telemetry into it and you meet throttling, rising latency, and a bill that scales badly. The fix is not a bigger Service Bus tier — it is recognising the workload is a stream and
