What is the difference between Service Bus, Event Grid, and Event Hub?

Service Bus vs. Event Grid vs. Event Hubs

All three move data between systems, but they solve different problems. The key distinction is the kind of thing being sent and who controls delivery.

• Service Bus is a message broker for business messages (commands, work items) that must be processed reliably.
• Event Grid is an event router for lightweight notifications that something happened ("reactive programming").
• Event Hubs is a streaming platform for ingesting huge volumes of telemetry and event data to be processed in order or analyzed.

Messages vs. events

• A message carries data with an intent: "process this order." The sender expects it to be handled, and cares about the outcome. Service Bus fits.
• An event is a fact that already happened: "a blob was created." The publisher doesn't care who reacts or how. Event Grid fits.
• A stream is a continuous, high-volume flow of events (millions per second) that consumers read and often replay. Event Hubs fits.

Delivery model

	Service Bus	Event Grid	Event Hubs
Model	Broker: queues and topics	Event routing (push)	Partitioned log (pull)
Who initiates delivery	Consumer pulls (or Functions trigger)	Event Grid pushes to handlers (webhooks, Functions, queues, etc.)	Consumer pulls and tracks its own position (offset/checkpoint)
Typical payload	Business message (commands, data)	Small event (metadata about what happened)	Telemetry, logs, clickstream
Message retention	Until consumed or TTL expires	Retries up to 24 hours (configurable), then dead-letter or drop	Retained for a set period (1 to 90 days by tier), regardless of consumption
Replay	No (once completed, gone)	No	Yes, consumers can re-read from any point in retention
Ordering	FIFO with sessions	Not guaranteed	Per partition
Transactions, duplicate detection	Yes	No	No
Dead-lettering	Yes (built in)	Yes (to storage, optional)	No
Scale focus	Reliability and features	Fan-out and many subscribers	Throughput (millions of events/sec)
Protocols	AMQP, HTTPS	HTTPS (webhook), CloudEvents	AMQP, Kafka, HTTPS

Typical use cases

Service Bus

• Order processing, payments, workflows where nothing can be lost
• Decoupling microservices and load leveling
• Ordered processing per entity (sessions) and transactional handling

Event Grid

• React to Azure resource events (blob created, resource deployed, Key Vault secret near expiry)
• Trigger a Function when a file lands in storage
• Publish your own custom events to many subscribers with filtering

Event Hubs

• IoT and device telemetry
• Application logs and metrics pipelines
• Clickstream and real-time analytics (with Stream Analytics, Spark, or Azure Data Explorer)
• Kafka-compatible ingestion without running Kafka yourself

A concrete example

An e-commerce system might use all three:

1. A customer places an order. The API puts an ProcessPayment command on a Service Bus queue, so it's handled exactly once per message, with retries and dead-lettering.
2. When the order invoice PDF is saved to Blob Storage, Event Grid notifies a Function to email it to the customer.
3. Every page view and click on the site streams into Event Hubs, where an analytics pipeline processes millions of events and can replay them if the logic changes.

Quick decision guide

• Does the message represent work that must be processed reliably, with ordering, retries, or transactions? → Service Bus
• Do you just need to react to something that happened, with push delivery to one or many handlers? → Event Grid
• Do you need to ingest massive streams and process or replay them? → Event Hubs

They can be combined

Event Grid is often used as the trigger layer in front of the others. For example, Event Grid can push an event into a Service Bus queue to get reliable, controlled processing, or Event Hubs capture files landing in Storage can raise Event Grid events. Treat them as complementary building blocks rather than competitors.