Event Grid
Azure Event Grid is a serverless event router. Publishers emit discrete events — a blob was created, a resource was deployed, a custom business event — and Event Grid delivers them to subscribers with filtering, retries, and dead-lettering. It is push-based, reactive integration: something happened, and interested handlers are notified.
An event is a notification, not a command. Event Grid carries 'this happened' to whoever cares; Service Bus carries 'do this' to a specific worker with reliability guarantees. Using Event Grid where you needed the durable, ordered processing of Service Bus — or the high-volume streaming of Event Hubs — is the classic mismatch.
Events and Schema
Event Grid handles small, discrete event messages and supports the CloudEvents standard schema, so events are portable across systems. An event describes what happened and carries enough to act or to fetch more — it is not the payload itself for large data, which stays in storage with the event pointing at it.
Topics and Subscriptions
Publishers send to a topic; subscribers create event subscriptions that route matching events to a handler. System topics emit events from Azure services themselves (Storage, Resource Manager, and more) with no setup; custom topics carry your application's own events. A subscription binds a source of events to a destination that handles them.
Filtering, Retries, and Dead-Lettering
Subscriptions filter by event type and by subject or data fields, so a handler receives only the events it cares about. Failed deliveries retry with backoff, and persistently undeliverable events go to a dead-letter location instead of being dropped. Filtering at the subscription is what keeps handlers from being woken for events they would only discard.
Push and Pull
Classic Event Grid is push — it calls your handler (a function, a webhook, a queue). The newer namespace model adds pull delivery and MQTT support for IoT scenarios, where many devices publish and consumers pull at their own pace. Push suits serverless handlers; pull suits high-fan-in device telemetry and consumers that control their own rate.
- Using Event Grid for durable, ordered, exactly-once work processing — that is Service Bus; events are fire-and-forget notifications.
- Pushing high-volume telemetry streams through Event Grid instead of Event Hubs, the streaming tool.
- Putting large payloads in events instead of a pointer to data in storage, bloating every delivery.
- Subscribing without filters, so handlers are invoked for events they immediately discard.
- Ignoring dead-lettering, so persistently failing deliveries are lost with no record.
- Assuming delivery order — Event Grid does not guarantee ordering; use Service Bus sessions when order matters.
- Use Event Grid for reactive, push-based notification of discrete events between decoupled components.
- Use system topics to react to Azure service events with no custom plumbing.
- Filter at the subscription by event type and subject so handlers receive only relevant events.
- Configure dead-lettering so undeliverable events are captured, not dropped.
- Keep events small — carry a pointer to large data in storage, not the data itself.
- Use the namespace model with pull and MQTT for IoT and high-fan-in device scenarios.
Knowledge Check
What is the conceptual difference between Event Grid and Service Bus?
- Event Grid carries event notifications ('this happened'); Service Bus carries commands ('do this') with reliability guarantees
- Event Grid is built for large multi-megabyte payloads streamed inline through each event, while Service Bus is restricted to carrying only small text-sized messages
- Event Grid guarantees strict ordering of events; Service Bus delivers them unordered
- They are interchangeable messaging services you can swap freely for one another
Why filter events at the subscription?
- So a handler is invoked only for events it cares about, instead of receiving and discarding the rest
- Filtering must be configured first or Event Grid will refuse to retry any failed delivery with exponential backoff
- It guarantees that matching events are delivered to the handler strictly in order
- It switches the subscription from push delivery to a pull-based model
When would you use Event Grid's namespace model with pull delivery and MQTT?
- For IoT and high-fan-in device telemetry where many devices publish and consumers pull at their own rate
- For durable, ordered command processing where each message must be handled exactly once by a single worker with delivery guarantees
- For deploying ARM templates that provision the underlying device infrastructure
- For caching static web content close to the devices that request it
You got correct