Azure Event Grid Architecture

Azure Event Grid is a fully managed, serverless event routing service that enables event-driven architectures. It acts as a central hub for events from various Azure services (e.g., Blob Storage, Resource Groups, Event Hubs) and custom applications, routing them to subscribers like Azure Functions, webhooks, or Logic Apps. Event Grid uses a publish-subscribe model where publishers emit events without knowing who will handle them, and subscribers express interest in certain event types.

Event Grid operates on a push-based model. When an event occurs (e.g., a blob is created), the publisher sends an HTTP POST request to Event Grid's endpoint. Event Grid then: 1. Validates the event schema. 2. Applies topic filters and subscription filters. 3. Forwards the event to each matching subscriber endpoint via HTTP POST. 4. If the subscriber does not acknowledge (HTTP 200 OK) within a timeout, Event Grid retries according to its retry policy. 5. After exhausting retries, the event can be sent to a dead-letter destination or dropped.

You can create custom topics and subscriptions via Azure Portal, CLI, or PowerShell. Example Azure CLI:

# Create a custom topic
az eventgrid topic create --name myTopic --location westus --resource-group myResourceGroup

# Create an event subscription to a webhook endpoint
az eventgrid event-subscription create \
  --name mySubscription \
  --source-resource-id /subscriptions/{sub-id}/resourceGroups/myResourceGroup/providers/Microsoft.EventGrid/topics/myTopic \
  --endpoint https://mywebhook.azurewebsites.net/api/events

To verify delivery, check subscriber logs or use Event Grid's diagnostic settings to stream events to a Log Analytics workspace.

| Feature | Event Grid | Event Hubs | Service Bus | |---------|------------|------------|-------------| | Primary use | Event routing | Data ingestion | Enterprise messaging | | Delivery model | Push | Pull (via consumer groups) | Pull (via queues/topics) | | Ordering | Not guaranteed | Per partition | First-in-first-out (queues) | | At-least-once | Yes | Yes | Yes | | Exactly-once | No | No | Yes (via dedup) | | Dead-letter | Yes | No (via capture) | Yes | | Throughput | Millions/s | Millions/s | Thousands/s |

Event subscriptions support filtering on:

Event Grid uses Shared Access Signatures (SAS) or managed identities for authentication. Subscribers must validate endpoints via a handshake (e.g., returning validationCode).

A media company uploads millions of images daily to Azure Blob Storage. They need to automatically generate thumbnails and apply watermarks. Using Event Grid, they subscribe to Blob Created events. When an image is uploaded, Event Grid triggers an Azure Function that resizes the image. The function writes the thumbnail to a different container. This pattern decouples upload from processing, allowing the storage service to scale independently. In production, they configured a dead-letter queue (Azure Queue Storage) to capture failed events (e.g., corrupted images). They set retry policy to 5 attempts over 10 minutes to avoid endless retries on permanent failures. Common issue: misconfigured subject filters caused functions to fire for every blob event, including small temp files, overwhelming the function. Solution: use subject prefix filter on /blobServices/default/containers/images/.

A large enterprise wants to react to Azure resource changes (e.g., VM creation, storage account deletion) for compliance auditing. They create a system topic for Azure subscriptions and subscribe to all resource write events. Events are sent to Event Hubs for long-term storage and to a Logic App that sends alerts to a Teams channel. Event Grid's built-in filtering ensures only events of interest (e.g., 'Microsoft.Resources.ResourceWriteSuccess') trigger alerts. They set up a second subscription to send all events to a Log Analytics workspace via diagnostic settings for later analysis. Pitfall: Event Grid's default retry policy caused duplicate alerts when the Logic App occasionally returned 500 errors. They configured a retry policy of 2 attempts to reduce duplicates while still handling transient failures.

A SaaS provider uses Event Grid as an internal event bus for microservices. Each microservice publishes events to custom topics (e.g., 'OrderPlaced', 'PaymentReceived'). Other microservices subscribe to relevant topics. This avoids tight coupling. They use advanced filtering on order value to route high-value orders to a premium processing service. Performance: they handle 500 events/second with <100ms latency. Issue: one subscriber's endpoint was slow, causing retries and back-pressure. They moved that subscriber to a queue (Service Bus) and used Event Grid to push events to the queue instead, decoupling the slow processor.