Have you ever been unsure whether to use Event Grid or Service Bus? Then this Friday Fact is for you!
This was one of the first questions I asked myself when I started learning these two technologies. In the Azure universe, few decisions are as fundamental to integration architecture as choosing between Event Grid and Service Bus. In a simplistic way, when you look at them, they seem to do the same thing: move data from one point to another asynchronously. Although they have common areas, their purposes differ radically, and choosing the wrong tool can lead to fragile, overly complex systems.
📝 One-Minute Brief
In the Azure universe, few decisions are as fundamental to integration architecture as choosing between Event Grid and Service Bus.
Here we are going to address some key differences betwwen these services.
Fortunately, again in a simplistic way, one simple question can help you resolve almost all of the uncertainty:
Am I notifying about something that happened (a fact), or am I sending a task to be executed (a command)?
If the answer is:
- Notifying about a fact > most likely, you should use Event Grid
- Sending a task >most likely, you should use Service Bus.
The World of Events: Reactive and Decoupled (Event Grid)
Think of an event as a public announcement—a lightweight signal that something has already happened.
- Examples:
- A new file was uploaded to Blob Storage
- A new user was added to Azure AD
Event Grid acts like an airport’s public address system. It announces the fact to anyone who might be interested (“Flight 123 is now boarding at gate 5”). The publisher of the event doesn’t know (or care) who will listen or what they will do with that information. It simply broadcasts the fact, allowing multiple systems to react independently and asynchronously.
Key characteristics of Event Grid:
- Reactive: Ideal for event-driven architectures.
- Push Distribution: Actively sends the event to subscribers.
- Lightweight: Events contain only information about what happened, not the complete data.
The World of Messages: Reliable and Transactional (Service Bus)
On the other hand, a message is a command—a unit of work that contains the data needed to perform a task by another service.
- Examples:
- Process this new order
- Generate the invoice for this customer
- Send a welcome email.
Service Bus is like a registered letter. It ensures that the message (the task) is safely delivered to a specific recipient. If the recipient isn’t available, Service Bus holds the letter until it can be collected. It guarantees delivery and order (if needed) and offers mechanisms for handling failures.
Key characteristics of Service Bus:
- Reliability: Guarantees message delivery.
- Transactional: Supports complex operations that either succeed completely or not at all.
- Ordering and Sessions: Can ensure messages are processed in the order they arrived.
The Practical Scenario: An Online Order
Imagine the process of an online store. Here, the two services work in perfect harmony:
- Customer places an order: The website publishes a message to a Service Bus queue with the command: ProcessOrder #1. The message contains all the shopping cart data.
- Order processing: A backend service reliably reads the message from the queue, processes the payment, and updates the database. This step is critical and cannot be lost.
- Order shipped: After processing, the backend service publishes an event to Event Grid with the fact: OrderShipped.
Reacting to the event: Multiple systems, which have subscribed to this event, react simultaneously:
- A notification service sends an email to the customer.
- A logistics system schedules the pickup.
- A data analytics tool registers the sale.
What About Event Hubs?
To complete the picture, there’s also Event Hubs, designed for data streaming and telemetry ingestion — not for discrete commands or events.
Think of it as a firehose of continuous data (e.g., IoT telemetry, logs, or clickstream data).
So while Event Grid and Service Bus handle individual messages or events, Event Hubs handles large-scale data streams.
| Use Case | Service | Analogy |
| Notify that something happened | Event Grid | Airport loudspeaker |
| Send a task to be done | Service Bus | Registered letter ️ |
| Stream continuous data | Event Hubs | Firehose of data |
Friday Fact Takeaway
The choice isn’t about which service is “better,” but which is right for the job. The next time you need to connect two systems, stop and ask yourself the correct questions to decide what to use.
To lazy to read? We’ve got you covered! Check out our video version of this content!
Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Sauron’s Action Figure for Sandro’s son, yep, not for me!
