Event Grid for event publication and fan-out

Overview

Azure Event Grid is a managed publish-subscribe service for routing events. It is designed for event notification: one system announces that something happened, and interested subscribers react independently.

Event Grid is commonly used to:

• React to Azure resource events.
• Trigger serverless workflows.
• Fan out application events to multiple handlers.
• Connect SaaS partner events to Azure workloads.
• Route storage, resource, security, or operational events.
• Build lightweight event-driven integrations.

For interviews, the important distinction is that Event Grid is not a general work queue. It delivers events that describe state changes. A publisher should not expect a specific subscriber to complete a business transaction. Subscribers must be idempotent because delivery is at least once and ordering is not guaranteed.

Core Concepts

Event Notification

An Event Grid event says that something happened:

BlobCreated
OrderSubmitted
UserRegistered
InvoiceApproved
ResourceWriteSuccess

The event should be a fact, not an instruction. A good event lets consumers decide whether they care and what to do.

Events are different from commands:

If the sender needs one worker to complete a required task, Service Bus is usually a better fit.

Publisher

A publisher sends events to Event Grid. Publishers can be:

• Azure services.
• Custom applications.
• Partner SaaS systems.
• MQTT clients in namespace scenarios.

The publisher should set stable event metadata and avoid depending on a particular subscriber. Event publication should usually happen after the source system commits its own state.

Event Source

The event source is where the event happened. Azure Storage can be the source for a blob-created event. A custom order service can be the source for an order-submitted event.

Good event-source design matters because subscribers often filter by source, subject, and event type.

Topic

A topic is the Event Grid resource that receives events. Topic types include:

• System topics for Azure service events.
• Custom topics for application events.
• Partner topics for SaaS provider events.
• Namespace topics in newer Event Grid namespace scenarios.

Use one topic for a related family of events. Avoid dumping unrelated domains into one topic because filtering and ownership become messy.

Event Subscription

An event subscription connects a topic to a destination. It defines:

• Which events are selected.
• Where selected events are delivered.
• Delivery mode and endpoint.
• Retry and dead-letter behavior.
• Optional filters.

One topic can have many event subscriptions. This is how Event Grid supports fan-out.

Event Handler

An event handler is the destination that receives the event. Common handlers include:

• Azure Functions.
• Webhooks.
• Service Bus queues or topics.
• Storage queues.
• Event Hubs.
• Logic Apps through webhooks.

Use an event handler that matches the workload. A short lightweight reaction can go directly to an Azure Function. Work that needs buffering, competing consumers, or DLQ processing may route Event Grid to Service Bus.

Fan-Out

Fan-out means one published event is delivered to multiple subscribers. For example, an OrderSubmitted event might trigger:

• Fraud checks.
• Customer notification.
• Analytics.
• CRM synchronization.
• Audit logging.

Each subscriber is independent. A failure in one subscription should not be treated as failure of the original event publication.

Event Shape

Event Grid supports CloudEvents and Event Grid schema. CloudEvents is preferred for interoperability.

A CloudEvents-style event includes common metadata:

{
  "specversion": "1.0",
  "type": "Contoso.Orders.OrderSubmitted",
  "source": "/services/orders",
  "id": "7a8f4df3a4b54d9f9a3fd3e3",
  "time": "2026-06-18T10:20:00Z",
  "subject": "/tenants/42/orders/100187",
  "datacontenttype": "application/json",
  "data": {
    "orderId": "100187",
    "tenantId": "42",
    "total": 149.95
  }
}

Keep event payloads small. If consumers need a large document, publish a pointer to durable storage.

Subject Design

The subject should help subscribers filter. Use a consistent path-like structure:

/tenants/{tenantId}/orders/{orderId}
/containers/{containerName}/blobs/{blobName}
/regions/{region}/shipments/{shipmentId}

Good subjects support broad and narrow filters. Poor subjects force every subscriber to receive and discard irrelevant events.

Filtering

Event subscriptions can filter by:

• Event type.
• Subject prefix or suffix.
• Advanced fields and operators.

Use filtering to reduce noise and isolate subscribers. Do not rely on filters as the only authorization mechanism. The handler must still validate and authorize any follow-up action it performs.

Push Delivery

With push delivery, Event Grid sends events to the configured destination. This is common for webhooks, Azure Functions, Service Bus, Event Hubs, and Storage Queue handlers.

The handler must acknowledge quickly. Long-running work should be handed off to a queue or durable workflow rather than holding the delivery request open.

Pull Delivery

With pull delivery in namespace topics, the subscriber connects to Event Grid and reads events. This gives the subscriber more control over when it consumes events and can be useful when a public inbound endpoint is not desirable.

Choose pull when:

• The consumer cannot expose a suitable endpoint.
• Private connectivity is important.
• The consumer wants explicit control over consumption.
• Processing must be paused without losing the subscription.

Delivery Guarantees

Event Grid delivery is at least once. It does not guarantee global ordering. A subscriber can receive duplicates or events out of order.

Subscriber code must:

• Use the event ID or business ID for idempotency.
• Tolerate missing prior events.
• Re-read authoritative state when necessary.
• Handle old events safely.
• Avoid assuming delivery order.

Retry Behavior

For push delivery, Event Grid retries failed delivery attempts according to its retry policy. Retry behavior protects transient endpoint failures, but it does not make the handler's side effects exactly once.

Handlers should return success only after they have durably accepted the event or safely handed it to a queue. If a handler does work and then fails before responding, Event Grid can redeliver the same event.

Dead-Lettering

Event Grid can send undelivered events to a dead-letter destination when delivery cannot succeed within retry limits or time-to-live.

Dead-lettering is not enabled by default. Configure it for important integrations where dropped events would be difficult to reconstruct.

A dead-letter process should inspect:

• Event subscription name.
• Event ID.
• Delivery attempts.
• Failure reason.
• Destination endpoint.
• Event age.

Then decide whether to replay, compensate, or ignore.

Event Grid and Service Bus Together

Event Grid and Service Bus are often used together:

• Event Grid reacts to a system event.
• It routes the event to a Service Bus queue.
• Service Bus buffers work and manages retries.
• Workers process messages with DLQ handling and idempotency.

This combination is useful when the event is a notification but the handling requires durable work distribution.

Security

Secure Event Grid at both sides:

• Publishers need permission to publish.
• Subscribers need permission to create subscriptions.
• Push delivery to Azure services can use managed identity where supported.
• Webhook endpoints must validate Event Grid handshakes and authenticate requests as appropriate.
• Handlers must authorize any business operation caused by the event.

Do not treat possession of an event as permission to perform privileged work.

Observability

Track:

• Publish failures.
• Delivery failures.
• Retry count.
• Dead-letter count.
• Handler latency.
• Handler response codes.
• Event age.
• Subscriber-specific error rates.
• Correlation IDs across event and handler logs.

Asynchronous fan-out failures are easy to miss when each subscriber owns a separate path.

Common Mistakes

• Using Event Grid as a required work queue.
• Assuming exactly once delivery.
• Assuming event ordering.
• Sending large payloads.
• Publishing before the source state is committed.
• Making webhooks perform long synchronous work.
• Omitting dead-lettering for important subscriptions.
• Putting secrets or sensitive data in event payloads.
• Creating topics with unclear ownership.
• Forgetting to make subscribers idempotent.

Best Practices

• Publish facts, not commands.
• Use CloudEvents for interoperability when possible.
• Design stable event types and subjects.
• Keep payloads small and versioned.
• Filter subscriptions to reduce irrelevant delivery.
• Use queues for long-running or high-value processing.
• Configure dead-lettering for important delivery paths.
• Make handlers idempotent.
• Log event ID, type, source, subject, and correlation ID.
• Treat event publication as part of the source system's consistency design.