CH11-02: Event Sources, Routing, and Event Grid

Goal

The previous section framed an event as a fact that something meaningful happened. This section focuses on how those facts move from producers to interested consumers.

Azure Event Grid is a managed event routing service. In plain language, it helps event sources announce changes and deliver those notifications to subscribers without the source calling every subscriber directly.

The durable idea is:

Event routing connects producers and consumers without making the producer own every consumer's reaction.

The Short Version

Event Grid is useful when a system needs to say:

This happened. Whoever cares can react.

It is not mainly for saying:

This specific receiver must complete this business work.

That second meaning usually points toward durable messaging, often with Service Bus.

The high-level Event Grid model looks like this:

Blob upload or business event
  -> Event Grid topic
  -> Filtered subscriptions
  -> Function, webhook, or container handler

The source publishes an event. Event Grid routes the event. Subscriptions decide which handlers receive it. Handlers own their reactions.

Event Sources

An event source is the system that knows something happened.

In Azure, event sources can include:

• Azure services, such as Storage, Resource Manager, or other platform services that emit events.

• Custom applications that publish business events.

• Integration components that translate external changes into Azure events.

The source should publish a meaningful event name and a stable payload. For example, BlobCreated is clearer than StorageAction. ContractDocumentUploaded is clearer than DocumentEvent if the business meaning matters.

Good event sources do not publish every internal implementation detail. They publish enough information for subscribers to understand what happened and find the related resource or business object.

Topics, Subscriptions, and Filters

Event Grid uses topics and subscriptions to route events.

Filters are important because not every subscriber should receive every event. A document-processing function may care only about uploaded PDFs. An audit subscriber may care about every upload. A notification handler may care only about uploads that require human review.

Filtering helps keep each subscriber focused on its own responsibility.

Event Grid's Job

Event Grid's job is routing notifications. It helps with fan-out, filtering, delivery, and integration with event handlers.

It does not make every downstream business outcome reliable by itself. If the handler receives an event and then needs to perform work that must complete, the design still needs to consider durable work storage, retries, idempotency, dead-letter handling, and monitoring.

A common pattern is:

Event Grid routes the notification
  |
  v
Small handler validates the event
  |
  v
Service Bus stores durable work when completion matters

This pattern keeps Event Grid in the routing role and Service Bus in the reliable work role.

Example: Blob Upload Fan-Out

Imagine a media platform. A user uploads a video file to Blob Storage. The upload itself becomes an event.

Video blob uploaded
  |
  v
Event Grid
  |-- Metadata Function
  |-- Thumbnail processor
  |-- Catalog indexer
  |-- Audit subscriber

Each subscriber has a separate reason to react:

The storage account or upload service does not need to know all of those consumers. It emits the event. Routing and subscription configuration decide who receives it.

If thumbnail generation becomes business-critical and must survive worker outages, the thumbnail handler can place a durable message on Service Bus. Event Grid still announces the upload; Service Bus protects the processing work.

Event Grid, Service Bus, and Event Hubs

These services are easy to mix up because all of them move information between systems. Use the communication meaning from Chapter 5:

The same architecture can use more than one. A blob event can route through Event Grid, create reliable processing work in Service Bus, and later emit telemetry to Event Hubs. The services are not interchangeable; they carry different communication contracts.

Common Mistakes

• Using Event Grid as a durable business command queue when the message really means "this work must be completed."

• Publishing events with vague names or payloads that force subscribers to guess what happened.

• Sending sensitive or excessive data in event payloads when subscribers only need an identifier and context.

• Forgetting that subscribers own their own validation, retry, idempotency, and failure behavior.

• Treating filters as a replacement for good event design.

If Someone Asks You

Where does Event Grid fit in event-driven architecture?

A good answer is:

Event Grid fits as the event routing layer. It receives notifications from Azure services or custom applications, applies subscriptions and filters, and delivers matching events to handlers. It is strongest when the producer should announce that something happened without directly owning every consumer's reaction. If a reaction becomes durable business work, I usually add Service Bus or another reliability mechanism.

What You Should Remember

Event Grid routes notifications that something happened; it does not own every processing outcome.

Questions to Check Your Understanding

1. What is an event source?

2. Why are filters useful?

3. When might Event Grid be insufficient by itself?