Event Grid vs Service Bus vs Event Hubs: which one should you use
Azure has three services that all move messages from one place to another: Event Grid, Service Bus and Event Hubs. In this article we are going to see which one fits better your use case.
In this article, I will start with a simple three-question rule, follow it with a side-by-side comparison, and then explain the differences that actually matter when choosing between them.
Decide which one you need
Ask these three questions, in this order.
- Does the message represent work that must actually get handled? If yes, choose Service Bus. Service Bus is designed for reliable application messaging. It supports retries, dead-letter queues, and ordered processing.
- Would you ever want to read the old messages again? If yes, choose Event Hubs. It keeps events for a retention period, and consumers can go back and read them again from an earlier position.
- Is something simply announcing that it happened or changed? If yes, choose Event Grid. A resource or application publishes an event and interested consumers subscribe to it.
Another thing to consider is volume. If you are dealing with a continuous stream of extremely large numbers of events, Event Hubs is usually the service designed for that workload.
Side by side
| Event Grid | Service Bus | Event Hubs | |
|---|---|---|---|
| Carries | Notifications that something happened | Commands, jobs and application messages | Continuous streams of events |
| How you get messages | Usually pushed to subscribers | Consumers receive from queues or subscriptions | Consumers read from a position in the stream |
| Ordering | No general ordering guarantee | Yes, if you use sessions | Yes, inside one partition |
| Re-read old messages | No | No | Yes, as long as they are still kept |
| Failure handling | Retries and optional dead-lettering | Retries and dead-letter queue | Consumer decides what to do |
| Typical use | Resource changes and notifications | Business workflows and background jobs | Telemetry, logs, clicks, IoT |
What you are actually signing up to
The easiest way I have found to remember the difference is this:
- With Event Grid, you subscribe to events from a source.
- With Service Bus, somebody deliberately sends a message to the bus.
- With Event Hubs, you read from a stream.
That is also the difference between an event and a command.
An event says: This happened.
A command says: Please do this.
Event Hubs is neither. It is more like: Here is another event in the stream.
Event Grid
Use Event Grid when something happens and other parts of your system may want to react.
A blob gets created, a resource changes, or a deployment finishes.
The publisher does not need to know who is listening.
Service Bus
Use Service Bus when the message represents work that should actually get done.
Queues are used when each message should be processed by one consumer. Topics let multiple subscriptions receive their own copy of a message.
Service Bus also gives you things such as:
- dead-letter queues
- sessions
- transactions
- scheduled messages
- duplicate detection
If you need those kinds of guarantees, Service Bus is usually the answer.
Event Hubs
Use Event Hubs when you are dealing with a continuous stream of data.
Think:
- logs
- telemetry
- clicks
- sensor readings
- IoT events
Consumers keep track of their own position in the stream, and reading an event does not remove it.
The combination you will often use
A common combination is Event Grid → Service Bus.
Event Grid notices that something happened. Service Bus makes sure the resulting work gets processed reliably.
For example: Blob uploaded → Event Grid → Service Bus → Worker
Feel free to drop me a comment if you found this article helpful.