Azure Event Grid and Event Hubs in .NET: When to Use Each

#csharp #dotnet #azure #programming

Azure offers three services with similar names but very different roles: Service Bus, Event Hubs, and Event Grid.

They all move data between parts of your system, so it is easy to assume they are interchangeable.
They are not.

I have already covered Azure Service Bus in detail - the reliable message broker for commands and workflows between services.

This post covers the other two and then shows you exactly when to reach for each.

In this post, we will explore:

Azure Event Grid: how it works
Using Azure Event Grid in .NET
Azure Event Hubs: how it works
Using Azure Event Hubs in .NET
Service Bus vs Event Hubs vs Event Grid: when to use each

Let's dive in.

Azure Event Grid: How It Works

Azure Event Grid is a fully managed event routing service.

It follows a simple idea: something happens, and Event Grid delivers a notification to everyone who cares.

That "something" is an event - a small message that says a change occurred:

A blob was uploaded
A resource was created
An order was placed.

Event Grid does not store your data or run your logic.
It takes events from publishers and pushes them to subscribers, fast and at scale.

Azure Event Grid consists of four parts:

Publishers - where events come from. Azure services like Blob Storage and Resource Groups emit system events automatically. Your own application publishes custom events to a custom topic.
Topic - the endpoint events are sent to. A system topic for Azure events, or a custom topic for your own.
Event subscriptions - the rules that connect a topic to a handler. Each subscription can be filtered by event type or subject, so a handler receives only the events it requested.
Event handlers - where events are delivered: an HTTP webhook, an Azure Function, a Service Bus queue, an Event Hub, and more.

How Event Grid Differs from Service Bus

The key difference is push versus pull.

Service Bus is a broker you pull from: your consumer connects, locks a message, processes it, and completes it. The consumer controls the pace.

Event Grid pushes: when an event occurs, Event Grid makes an HTTP call to your handler. You do not poll - you expose an endpoint and wait to be called.

A few more differences matter:

Reactive notifications, not message transport. An Event Grid event is a lightweight signal ("blob X was created"), not a payload meant to carry megabytes of data. Service Bus messages can carry the full payload your consumer needs.
No ordering, no sessions. Event Grid does not guarantee order. Service Bus offers FIFO ordering through sessions.
Retries and dead-lettering work differently. Event Grid retries a failed HTTP delivery with backoff for up to 24 hours, then dead-letters to a Storage account you configure. Service Bus has a built-in dead-letter sub-queue on every queue and subscription.
Serverless and pay-per-event. Event Grid has no namespace to provision or scale - you pay per operation. Service Bus runs in a provisioned namespace.

Use Event Grid when you want many parts of your system to react to something that happened, especially Azure resource changes.

👉 Read the full article on my newsletter: https://antondevtips.com/blog/azure-event-grid-and-event-hubs-in-dotnet