Choosing Between Service Bus, Event Grid, and Event Hubs

Azure provides three messaging and eventing services, each designed for different scenarios. Choosing the wrong service leads to over-engineering, under-engineering, or architectural mismatches that are costly to fix. This lesson provides a clear decision framework based on the characteristics of your workload.

---

Quick Comparison

Dimension	Service Bus	Event Grid	Event Hubs
Purpose	Enterprise message broker	Serverless event routing	Big-data streaming platform
Pattern	Queue + pub-sub (topics)	Pub-sub (reactive)	Partitioned log (streaming)
Message model	Messages (commands/work)	Events (notifications)	Events (data stream)
Max message size	256 KB (Standard), 100 MB (Premium)	1 MB (64 KB recommended)	1 MB (Standard), 1 MB (Premium/Dedicated)
Delivery	At-least-once, at-most-once	At-least-once	At-least-once
Ordering	FIFO (within session or partition)	No ordering guarantee	FIFO within partition
Retention	Until consumed	Retry window (up to 24 hours)	1–90 days (or unlimited)
Throughput	Thousands/second	Millions/second (lightweight)	Millions/second (data-heavy)
Protocol	AMQP 1.0, HTTP	HTTP (webhooks, CloudEvents)	AMQP 1.0, HTTP, Kafka
Pricing	Per-message + base	Per-event (pay for what you use)	Per throughput/processing unit + time
Dead-lettering	Built-in sub-queue	To Blob Storage	No built-in DLQ
Transactions	Yes	No	No
Sessions	Yes	No	No
Duplicate detection	Yes	No	No

---

Decision Framework

Step 1: What Are You Sending?

The first question is whether you are sending messages (commands, work items) or events (notifications, telemetry).

• Messages → Service Bus
• Events → Event Grid or Event Hubs

Step 2: What Is the Volume and Nature?

If you are sending events:

• Discrete, reactive events (resource changes, webhooks, notifications) → Event Grid
• High-volume, continuous data streams (telemetry, logs, clickstreams) → Event Hubs

Step 3: Do You Need Advanced Messaging Features?

If you need any of the following, use Service Bus:

• FIFO ordering with sessions
• Transactions across multiple messages
• Dead-letter queue with automatic handling
• Duplicate detection
• Scheduled messages
• Message deferral

Step 4: Do You Need Kafka Compatibility?

If your team already uses Apache Kafka or you need Kafka-compatible producers/consumers → Event Hubs (with Kafka endpoint).

---

Scenario-Based Guidance

Scenario 1: Order Processing Pipeline

Requirements: Reliable delivery, ordering per order, dead-lettering for failed orders, duplicate prevention.

Best choice: Service Bus (queue with sessions and duplicate detection)

Why:

• Sessions ensure all steps for one order are processed in sequence
• Dead-lettering captures failed orders for investigation
• Duplicate detection prevents double-charging
• At-least-once delivery with PeekLock ensures no order is lost

Scenario 2: React to Azure Resource Changes

Requirements: Trigger a function when a blob is uploaded, a VM is created, or a key vault secret is updated.

Best choice: Event Grid (system topics)

Why:

• Native integration with Azure services — no custom publisher needed
• Sub-second delivery to Azure Functions, Logic Apps, or webhooks
• Pay-per-event with no idle cost
• Filtering by event type, subject, and advanced fields

Scenario 3: IoT Telemetry Ingestion