CH05-03: Event Routing with Event Grid

Goal

The previous section focused on reliable work handoff with Service Bus. This section turns to event notification: telling interested systems that something happened.

Azure Event Grid is a fully managed publish-subscribe service for routing events from sources to handlers. In plain language, it helps systems react to changes without hardwiring the publisher to every consumer.

The durable idea is:

Event Grid tells interested systems that something happened so they can react.

The Short Version

An Event Grid event is usually a notification, not a command.

It says:

Something happened.

It usually does not say:

You, specific receiver, must complete this business transaction.

That difference matters. Event Grid is strong when a producer should not need to know who is listening. A storage account can announce that a blob was created. An application can announce that an order was created. A platform service can announce that a resource changed. Subscribers can react independently.

Blob uploaded -> Event Grid
                                    |-- Function creates thumbnail
                                    |-- Workflow notifies reviewer
                                    |-- Service Bus message starts durable processing

Each subscriber has its own reason to care about the same event.

Event Notification

Event notification is useful when the publisher wants to announce a fact.

Examples:

• A file was uploaded.

• An order was created.

• A resource was modified.

• A payment status changed.

• A customer profile was updated.

The publisher does not need to call every downstream system directly. It publishes the event, and Event Grid routes it to configured handlers.

This reduces point-to-point coupling. New subscribers can be added without changing the publisher. Existing subscribers can be removed without changing the publisher. That is the architectural value of event routing.

Fan-Out

Fan-out means one event can reach multiple subscribers.

For example, a product image upload might trigger several reactions:

The upload service should not need to know all of those subscribers. Its job is to publish the event. Subscribers own their reactions.

Fan-out works well when reactions are independent. If the steps must happen in a strict sequence, or if a business process needs central state and error handling, a workflow or durable messaging design may fit better.

Event Grid Is Not a Business Work Queue

Event Grid can retry delivery and can support dead-lettering for undelivered events in some designs. That does not make it the same as Service Bus.

Use Event Grid when the main need is event distribution and reaction.

Use Service Bus when the main need is reliable business work processing with enterprise messaging features such as durable queues, topics, transactions, sessions, duplicate detection, or stronger command-processing semantics.

A practical pattern is to combine them:

Blob uploaded -> Event Grid -> Function validates metadata
                                                            |
                                                            v
                                                    Service Bus Queue: process-image-assets

Event Grid starts the reaction. Service Bus carries the durable work when the reaction becomes business-critical processing.

Event Design

Good event design is not only about routing.

Teams should decide:

• What event types exist.

• Who owns the event schema.

• Whether the event includes full data or only identifiers.

• How subscribers handle unknown event versions.

• Which subscribers receive which events.

• What happens when a handler fails.

• How correlation IDs connect event handling to the original business action.

• Whether sensitive information should be omitted from event payloads.

Events can create accidental coupling if they expose too much internal detail. A small, stable event contract is often better than a large payload that every consumer starts depending on.

Example: Product Image Upload

Imagine a retail platform where sellers upload product images.

The upload service stores the image and publishes an event:

Product image uploaded
    productId: 12345
    blobUrl: pointer to stored image
    uploadedBy: seller identity or system identity
    correlationId: original upload request

Event Grid routes the event:

The upload service stays simple. It stores the image and announces the fact. Other systems react according to their own responsibilities.

Common Mistakes

• Treating Event Grid as a durable queue for business commands.

• Building tight coupling through event payloads that expose too much internal detail.

• Forgetting ownership of event schemas and subscribers.

• Ignoring what should happen when an event handler fails.

• Publishing sensitive data in events that many subscribers can see.

• Assuming event-driven design is automatically simpler than direct calls.

If Someone Asks You

When should you use Event Grid instead of Service Bus?

A good answer is:

I use Event Grid when a system needs to announce that something happened and route that event to interested subscribers. I use Service Bus when the message represents reliable work that must be processed. Event Grid is about notification and reaction. Service Bus is about durable work handoff. They can work together when an event starts a process that later needs reliable queue-based processing.

What You Should Remember

Event Grid is best for routing change notifications to systems that need to react.

Questions to Check Your Understanding

1. Why is an event different from a command?

2. What makes fan-out useful in event-driven design?

3. When might an Event Grid handler send work to Service Bus?