Event Grid vs Service Bus vs Event Hubs: events, messages, and streams
Three Azure services move data between components, and picking wrong makes a system either lose things it needed or over-engineer things it didn't. The choice gets easy once you learn one distinction: an event is not a message.
As soon as an architecture has more than one moving part, those parts need to talk without being wired directly together. Azure offers three services for that — Event Grid, Service Bus, and Event Hubs — and they are constantly confused because they all "send data between things." They are not interchangeable. The clean way in is a definition Microsoft draws sharply: the difference between an event and a message.
Event vs message — the distinction everything hangs on
Straight from the docs:
- An event is "a lightweight notification of a condition or state change," where "the publisher has no expectation about how the event is handled." It shouts "an order was placed!" into the room and moves on, indifferent to who listens.
- A message is "raw data produced by a service to be consumed or stored elsewhere," and crucially, "a contract exists between publisher and consumer." The sender expects that specific work will be done with it.
Indifferent notification versus data-with-a-contract. Hold that, and the three services sort themselves.
The three services
- Event Grid — reactive event routing. Its job is distributing discrete events to whoever subscribed, serverless and near-real-time. Use it to react to status changes: a blob was created, a resource was deployed, an order shipped. It broadcasts; subscribers react.
- Service Bus — enterprise message broker. This is for high-value messages that must be handled reliably and in order. It offers the features that transactional work demands: FIFO ordering (via sessions), transactions, duplicate detection, and dead-lettering. Use it for order processing, financial transactions, and workflows — anywhere losing or double-processing a message is unacceptable.
- Event Hubs — big-data streaming. Built to ingest millions of events per second as a time-ordered stream. Use it for telemetry, clickstreams, and real-time analytics — a firehose you capture and process, not discrete notifications you react to one by one.
| Event Grid | Service Bus | Event Hubs | |
|---|---|---|---|
| Moves | Events (notifications) | Messages (with a contract) | Event streams |
| Purpose | Reactive routing | Transactional messaging | Big-data ingestion |
| Ordering | No guarantee | FIFO (sessions) | Per partition |
| Transactions | No | Yes | No |
| Use for | "An order shipped" | "Process this order" | Telemetry & analytics |
An event says "this happened." A message says "do this with this." A stream says "here is everything, in order, forever."
These are not competitors fighting for one slot. Microsoft's own example: an e-commerce site can use Service Bus to process orders reliably, Event Hubs to capture site telemetry, and Event Grid to react to events like an item shipping — all at once. Mature systems use the right one for each job rather than forcing everything through a single pipe.
How to choose
- Reacting to something that happened, and the publisher does not care how? Event Grid.
- Handing off work that must be processed reliably, in order, maybe transactionally? Service Bus.
- Ingesting a huge, continuous firehose of telemetry for analytics? Event Hubs.
The failure mode to avoid is reaching for the one you know. Pushing financial transactions through Event Grid loses you ordering and transactions; pushing millions of telemetry points through Service Bus is the wrong tool at the wrong scale. Ask first "is this a notification, a unit of work, or a stream?" — and the service names itself. Answering an interviewer with that framing ("an event with no contract, so Event Grid") shows you understand messaging, not just the logos.