Azure Service Bus vs Event Hub: Key Differences

The most common Azure messaging mistake is using Event Hub where Service Bus is needed. Both services move data from producers to consumers. The similarity stops there. They are built for fundamentally different scenarios, and choosing the wrong one does not fail loudly. It fails gradually, with messages lost under load, consumers falling behind in ways they cannot recover from, or ordering guarantees you assumed turning out not to exist.

Here is the actual difference, when each is right, and what breaks when you use the wrong one.

The fundamental distinction

Azure Service Bus is enterprise messaging. It is designed for discrete messages where each one represents a unit of work that must be processed, must be processed exactly once, and must not be lost. An order placed. A payment to process. A notification to send. Service Bus guarantees delivery, supports transactions, maintains message ordering within sessions, handles poison messages via dead-letter queues, and allows consumers to process messages at their own pace without losing them.

Azure Event Hubs is event streaming. It is designed for high-volume streams of events where what matters is the stream as a whole, not each individual event in isolation. Telemetry from IoT devices. Clickstream data from a website. Application logs. Transaction records for analytics. Event Hubs ingests millions of events per second, retains them for a configurable period, and allows multiple consumer groups to read the same stream independently.

The test: does each individual message represent a unit of work that must happen? Service Bus. Is the value in the aggregate stream of events? Event Hubs.

Service Bus: what it does that Event Hubs does not

Guaranteed delivery. Service Bus guarantees that every message is delivered at least once. A message stays in the queue until a consumer receives it and explicitly completes it. If the consumer fails to complete the message (because it crashes, because processing fails), the message returns to the queue and is redelivered after a lock timeout. It does not disappear.

Dead-letter queues. Messages that cannot be processed (malformed, repeatedly failing, expired) are moved to a dead-letter sub-queue rather than being lost. You can inspect the dead-letter queue, understand why messages failed, and replay or discard them deliberately. This is critical for any workflow where a processing failure needs human attention.

Message ordering with sessions. Service Bus sessions group related messages so they are processed in order by the same consumer. An order with multiple line items, a workflow with sequential steps: sessions ensure the messages arrive at the same consumer in the right sequence.

Transactions. Service Bus supports atomic operations across multiple queue or topic operations. Enqueue a message and dequeue another in a single atomic transaction. This matters for workflows that update multiple queues as part of a single logical operation.

Topics and subscriptions. A Service Bus topic is a publish-subscribe mechanism. Multiple subscribers each get a copy of every message, filtered by rules. An order-placed message can go to a fulfilment subscriber, an inventory subscriber, and a notification subscriber simultaneously, each processing independently.

Message size: up to 256 KB on Standard tier, up to 100 MB on Premium tier.

Event Hubs: what it does that Service Bus does not

Throughput at scale. Event Hubs is designed for millions of events per second. It partitions the stream across throughput units (Standard tier) or processing units (Premium and Dedicated), scaling horizontally in a way that Service Bus cannot. If your producer can generate 100,000 events per second, Event Hubs handles it. Service Bus does not.

Replay. Event Hubs retains events for a configurable period (1 to 90 days on Standard tier). Consumers can rewind to any point in the stream and re-read events. If a bug in your consumer causes incorrect processing, you can fix the bug and replay from the beginning of the retention window. Service Bus messages are gone once consumed.

Multiple independent consumer groups. Multiple applications can read the same Event Hub stream independently, each maintaining its own position (offset) in the stream. An analytics system and an alerting system can both consume the same telemetry stream without one affecting the other.

Kafka compatibility. Event Hubs exposes a Kafka-compatible endpoint. Applications using the Kafka protocol can send events to Event Hubs without code changes. This makes it a managed alternative to Kafka for teams already using the Kafka API.

Capture. Event Hubs can automatically capture raw events to Azure Blob Storage or Data Lake Storage, creating a persistent archive of the raw stream. This is separate from the retention window: captured data can be kept indefinitely.

Event size: up to 1 MB per event.

The comparison at a glance

	Service Bus	Event Hubs
Primary pattern	Command / message queue	Event streaming
Typical producers	Applications sending discrete work	Devices, applications emitting telemetry
Message retention	Until consumed or expired	Time-based window (1-90 days)
Replay	No	Yes
Guaranteed delivery	Yes	Best-effort (no consumer acknowledgment)
Dead-letter handling	Built-in DLQ	Not built-in
Max throughput	~10 MB/s per namespace (Premium)	Millions of events/second
Max message size	100 MB (Premium)	1 MB
Ordering	Sessions for ordered delivery	Per-partition ordering
Multiple consumers	Topics + subscriptions	Consumer groups
Transactions	Yes	No

When you need both

Some architectures use both services at different stages. A common pattern: Event Hubs ingests a high-volume stream of raw events. A stream processor (Azure Stream Analytics or Azure Functions) reads from Event Hubs, enriches or filters the events, and puts the resulting work items onto a Service Bus queue for downstream processing with delivery guarantees.

This separation is intentional: the ingestion layer (Event Hubs) absorbs the volume, the processing layer (stream processor) transforms it, and the work queue layer (Service Bus) provides the reliability guarantees for the consequential downstream actions.

Common mistakes

Using Event Hubs for command messages. Event Hubs does not guarantee delivery in the way Service Bus does. If a consumer is offline when an event is ingested and the retention window expires before the consumer catches up, the event is gone. For commands that must be processed (send this notification, charge this card), this is data loss.

Using Service Bus for high-volume streaming. Service Bus will queue the messages, but throughput limits mean it cannot ingest a high-frequency telemetry stream. You will see throttling, back-pressure, and eventually queue depth issues under load.

Ignoring the dead-letter queue in Service Bus. The dead-letter queue fills up silently. If nobody is monitoring it, failed messages accumulate indefinitely, and the production issue they represent goes unnoticed.

Assuming Event Hubs provides per-event ordering. Event Hubs provides ordering within a partition. If your producer sends events across multiple partitions (the default), ordering across partitions is not guaranteed. If strict ordering matters, use a partition key to pin related events to the same partition.

Where Critical Cloud comes in

Messaging architecture decisions are hard to change after they are embedded in production systems. Choosing the wrong service, or getting the consumer patterns wrong on the right service, creates reliability problems that are expensive to diagnose and painful to fix. We design and operate messaging architecture for technology-led businesses on Azure, with Datadog integration giving us visibility into queue depths, consumer lag, dead-letter queue growth, and throughput as live operational signals. As the world's first Powered by Datadog accredited partner, we treat messaging health as a first-class operational concern, not an afterthought. See how Critical Support works.