Many systems waste effort asking “has anything changed?” over and over. Events turn that around.

Polling versus being told

The simplest way for one system to learn about changes in another is polling: ask every few seconds, “Is there anything new?” Polling is wasteful, because most answers are “no”, and slow, because a change is noticed only at the next question. It also couples systems tightly, since the asker must know where to look and how often.

An event-driven design reverses the flow. When something happens, the system where it happened publishes a small message called an event: a short, factual statement that something occurred, such as “a file was uploaded” or “an order was placed”. Other systems that care subscribe and are told right away. The sender does not need to know who is listening, how many listeners there are, or what they will do.

What Event Grid does

Azure Event Grid is a fully managed service for routing events from sources to handlers. It receives events from Azure services, from your own applications, and from partner services, and delivers them to the places that asked for them, with filtering, retries and dead-lettering built in. It scales automatically and you pay for what you use, with no servers to run.

Six words explain almost everything in Event Grid.

flowchart LR
  S["Event source"] -->|Publishes events| T["Topic"]
  T --> SUB1["Subscription A with filter"]
  T --> SUB2["Subscription B with filter"]
  T --> SUB3["Subscription C with filter"]
  SUB1 --> H1["Handler: function"]
  SUB2 --> H2["Handler: queue"]
  SUB3 --> H3["Handler: webhook"]
        

What an event looks like

An event is mostly a labelled envelope with a few standard fields, plus a data section with details that depend on the event. Typical envelope fields identify the event, say what kind of event it is, name the subject it is about, record when it happened, and say what version of the schema it follows. The data section carries the specifics, such as the name and size of a file. Events are meant to be small and factual. They tell handlers that something happened and where to look, not necessarily everything about it.

Not every piece of data sent between systems is an event. The distinction decides which Azure service fits.

Reactive programming and discrete events

Event Grid is built for discrete events: individual, separate happenings that someone may want to react to. Examples are a file added, a virtual machine created, a deployment finished, or an order placed. It is not built for continuous streams, such as a million sensor readings a second, where the interest lies in the flow as a whole. For streams, Event Hubs is the usual choice, and Event Grid can be combined with it when stream data needs to trigger discrete reactions.

A topic is where events are sent. Which kind you use depends on who the source is.

flowchart TD
  A["Azure services such as Storage or Resource Manager"] --> ST["System topic"]
  B["Your applications"] --> CT["Custom topic"]
  C["Partner SaaS service"] --> PT["Partner topic"]
  D["Multi-tenant application"] --> DM["Event domain with many topics"]
  ST --> SUBS["Event subscriptions"]
  CT --> SUBS
  PT --> SUBS
  DM --> SUBS
  SUBS --> HAND["Handlers"]
        

When to use event domains

If you build a multi-tenant application where every customer needs a separate topic with its own access and subscriptions, creating thousands of individual topics would be hard to manage. An event domain gives you one endpoint to publish to, with the topic named inside each event, and lets you grant each customer rights only to its own topic. It is a good fit for software-as-a-service products that want to expose events to customers.

A subscription connects a topic to a handler and says which events to deliver.

An event subscription belongs to a topic and defines three things: the filter that selects events, the destination where matching events are delivered, and the delivery rules such as retries, expiry and dead-lettering. Many subscriptions can exist on one topic, and each receives its own copy of every matching event. That is the fan-out behavior: one event, many independent reactions.

sequenceDiagram
  participant SRC as Source
  participant TOP as Topic
  participant SUB as Subscription with filter
  participant HAN as Handler
  SRC->>TOP: Publish event
  TOP->>SUB: Offer event to each subscription
  SUB->>SUB: Check filter
  SUB->>HAN: Deliver if matched
  HAN-->>SUB: Success response
  Note over SUB,HAN: If no success, retry later according to policy
        

Event Grid delivers to many kinds of destination. The right one depends on what must happen next.

flowchart LR
  E["Event: file uploaded"] --> G["Event Grid"]
  G --> F["Function: scan the file"]
  G --> L["Logic App: notify the team"]
  G --> Q["Queue: buffer for batch processing"]
  G --> H["Event Hub: feed analytics stream"]
        

Buffering with a queue

Sometimes the handler cannot keep up with bursts of events, or must process them carefully, one by one. A queue between Event Grid and the handler absorbs the burst: Event Grid delivers quickly to the queue, and the handler pulls work at its own pace. This is a very common and robust pattern, and it combines the broadcast strength of Event Grid with the control strength of Service Bus.

An agreed shape for events lets different systems understand each other.

Why a standard schema matters

If every team invents its own event format, every consumer must learn every format, and changing one breaks others. A standard envelope means tools, filters and monitoring work the same way for all events. The data section can still be specific to each event type. Treat the data shape as a public contract: version it, add fields rather than renaming or removing them, and document it where consumers can find it.

Good filters save money, reduce load and keep handlers simple.

flowchart TD
  EV["Incoming event"] --> T{"Event type matches?"}
  T -->|No| DROP["Not delivered to this subscription"]
  T -->|Yes| S{"Subject matches prefix and suffix?"}
  S -->|No| DROP
  S -->|Yes| A{"Advanced conditions satisfied?"}
  A -->|No| DROP
  A -->|Yes| DEL["Deliver to handler"]
        

Filter at the source of truth

Filter in the subscription rather than inside the handler whenever possible. Filtering in the subscription means unwanted events are never delivered, never billed as deliveries to that handler, never start a function, and never create noise in logs. It also makes the intent visible: anyone reading the subscription sees exactly which events trigger which reaction.

What happens when the handler is slow, busy or down?

Event Grid guarantees at-least-once delivery for the push model. That means that every event is delivered at least one time to every matching subscription, and in rare cases it may be delivered more than once. It does not promise ordering. Handlers must therefore be able to cope with duplicates and with events arriving in a different order than they happened.

The retry story

When a delivery attempt fails or the handler does not respond with a success code in time, Event Grid retries with increasing waits between attempts, a pattern called exponential backoff. By default it keeps trying for up to a day, for a limited number of attempts, and you can shorten both. Some failures are treated as permanent, for example when the destination does not exist or rejects the request as unauthorized, and are not retried in the same way. Slow or unhealthy endpoints may also have their deliveries delayed to protect them from being overwhelmed.

flowchart TD
  A["Event matched"] --> B["Attempt delivery"]
  B --> C{"Success response?"}
  C -->|Yes| D["Done"]
  C -->|No| E{"Retry window and attempts left?"}
  E -->|Yes| F["Wait with increasing delay"]
  F --> B
  E -->|No| G{"Dead-letter configured?"}
  G -->|Yes| H["Store event in blob storage with failure reason"]
  G -->|No| I["Event is dropped"]
        

Dead-lettering

If delivery ultimately fails, the event can be saved in a storage container you choose, together with information about why it failed. This is called dead-lettering. Without it, such events are simply dropped. Enable dead-lettering on every subscription that matters, monitor the container, and create a procedure for examining and replaying events once the underlying problem is fixed.

Designing handlers for duplicates and disorder

Make handlers idempotent: processing the same event twice must have the same final effect as processing it once. A common approach is to record the identifier of each processed event, or to design operations as “set to this value” instead of “add one”. For disorder, do not assume that “created” arrives before “updated”. Use timestamps or version numbers in the data to decide whether an event is newer than what you already have.

Event Grid will not send events to an address until it is sure the owner agrees.

If anyone could point Event Grid at any web address, the service could be used to flood a stranger’s server. To prevent this, when you create a subscription to a webhook, Event Grid first sends a special validation event. The endpoint must prove it controls the address, either by echoing back a code included in the validation event or by visiting a validation address provided. Many Azure destinations, such as Functions with an Event Grid trigger, queues and Event Hubs, are validated automatically when you have rights to them.

sequenceDiagram
  participant EG as Event Grid
  participant WH as Webhook endpoint
  EG->>WH: Send validation event with a code
  WH-->>EG: Echo the code or confirm validation
  EG->>EG: Mark subscription as validated
  EG->>WH: Begin sending real events
        

Besides Azure’s built-in events, your applications can announce their own.

To publish to a custom topic or domain, an application sends events to the topic’s web address over a secure connection, authenticating either with an access key, a shared access signature or, preferably, a Microsoft Entra identity that has been granted a data sender role on the topic. Events can be sent in batches to improve efficiency. The publisher gets a success response once Event Grid has accepted the events, which means the events are stored and will be delivered; it does not mean any handler has finished.

The outbox idea

A subtle problem arises when an application must both save data in its database and publish an event. If it saves and then crashes before publishing, the event is lost. If it publishes and then fails to save, listeners react to something that never happened. A well-known solution is the outbox pattern: the application writes the event into a table in the same database transaction as the business change, and a separate small process reads that table and publishes the events, marking them as sent. This gives reliable publishing, and combined with idempotent handlers it gives dependable end-to-end behavior.

flowchart LR
  APP["Application"] -->|One transaction| DB["Database: business data plus outbox table"]
  DB --> REL["Relay process reads unsent events"]
  REL -->|Publish| EG["Event Grid topic"]
  REL -->|Mark as sent| DB
        

A newer part of Event Grid broadens what it can do beyond classic push delivery.

Alongside the original topics, Event Grid offers a namespace, a container that hosts newer capabilities. Two stand out. First, an MQTT broker: MQTT is a lightweight messaging protocol widely used by devices and sensors, built around publishers and subscribers exchanging messages on named topics. The namespace can accept connections from many devices, route their messages to each other, and also route them onward to Azure handlers. Second, pull delivery: instead of Event Grid pushing events to a handler, the handler connects and pulls events from a namespace topic at its own pace, then acknowledges, releases or rejects each one.

flowchart LR
  D1["Device 1"] -->|MQTT publish| N["Event Grid namespace MQTT broker"]
  D2["Device 2"] -->|MQTT publish| N
  N -->|MQTT subscribe| APP["Control application"]
  N -->|Route to namespace topic| NT["Namespace topic"]
  NT -->|Pull| PROC["Processing service"]
        

Many Azure services announce events without any extra code from you.

A few designs appear again and again.

Pattern 1: Fan-out reaction

One event, many independent reactions. A file upload triggers a virus scan, a thumbnail creator, a metadata indexer and an audit log entry, each through its own subscription. Adding a fifth reaction later requires no change to the uploader.

Pattern 2: Event-carried notification with fetch

The event is small and holds identifiers. Handlers who need more details call the source service to fetch them. This keeps events cheap and avoids sending stale or sensitive data around.

Pattern 3: Choreography

Services react to each other’s events without a central controller. Order service announces “order placed”; payment service reacts and announces “payment taken”; shipping service reacts and announces “parcel dispatched”. Each service knows only the events it consumes and produces. It is flexible, but the overall flow becomes harder to see, so document it and trace it.

Pattern 4: Orchestration with events as triggers

A workflow service coordinates a long process and uses events to start it or to wake it when something external happens. This gives visibility and control for processes with many steps, approvals and compensation.

Pattern 5: Buffered integration

Event Grid delivers into a queue so that downstream systems process at their own pace and failures are isolated.

flowchart LR
  OS["Order service"] -->|Order placed| EG["Event Grid"]
  EG --> PS["Payment service"]
  EG --> INV["Inventory service"]
  EG --> NOT["Notification service"]
  PS -->|Payment taken| EG2["Event Grid"]
  EG2 --> SH["Shipping service"]
  EG2 --> NOT
        

Three messaging services, three different jobs.

They are often combined

Events can reveal what is going on inside your systems, and the right to publish them can cause actions. Both deserve protection.

Controlling who can publish and who can subscribe

flowchart LR
  PUB["Publisher with identity"] -->|Token over TLS| TOP["Topic with role assignment"]
  TOP --> EG["Event Grid"]
  EG -->|Managed identity| H1["Queue or function handler"]
  EG -->|Managed identity| DL["Dead-letter storage"]
  PUB2["Unknown caller"] -.->|Rejected| TOP
        

Network protection

By default topics and domains are reachable through public endpoints, protected by authentication and always encrypted in transit. For tighter control you can restrict access to selected address ranges, or use private endpoints so publishers inside your virtual network reach the topic over private addresses and public access is turned off. Delivery to handlers behind private networks needs separate planning: in some cases, trusted-service access or a queue as an intermediate handler can help, and pull delivery lets a private consumer fetch events with outbound connections only.

Protecting the data in events

Events pass through the service, logs, dead-letter storage and handlers. Keep them free of secrets and unnecessary personal data. Where sensitive details are needed, include only an identifier and let authorized handlers fetch the details from the source. Encrypt dead-letter storage, restrict who can read it, and set retention to match policy.

Event-driven systems are quiet when they work and puzzling when they do not. Make them observable.

What to watch

flowchart LR
  EG["Event Grid topics and subscriptions"] --> M["Metrics"]
  EG --> D["Diagnostic logs for delivery failures and publish errors"]
  M --> AL["Alert rules"]
  D --> LA["Log Analytics workspace"]
  LA --> AL
  AL --> AG["Action group"]
  AG --> T["Team channel or on-call tool"]
        

Troubleshooting checklist

Events are only useful if they survive failures, so plan for the bad days.

What the service gives you

Event Grid is built on regional infrastructure with redundancy within the region, and it can use availability zones in supported regions. Once an event is accepted, it is stored and delivered with retries as described earlier. The service does not guarantee ordering, and it does not keep events forever; its job is to deliver or dead-letter them.

Regional failures

For regional disasters, Event Grid has offered geo-disaster recovery features for custom topics and domains, with options to publish to a paired secondary topic, and to fail over. The details, including which topic types support them and who controls failover, have changed over time, so verify the current model. A common design is to keep a matching topic and subscriptions in a second region, defined as code, and make publishers capable of switching if the primary is unreachable.

flowchart LR
  PUB["Publisher with failover logic"] --> P["Primary region topic"]
  PUB -.->|If primary unreachable| S["Secondary region topic"]
  P --> H1["Handlers in primary region"]
  S --> H2["Handlers in secondary region"]
  REPO["Templates in source control"] --> P
  REPO --> S
        

Event Grid is usually inexpensive, but high volumes and extra features add up.

For the classic service, pricing is generally based on the number of operations, counting things like event publishes, delivery attempts, advanced filter evaluations and management calls, with a monthly free allowance and a price per million operations beyond it. Namespace features such as MQTT and pull delivery use their own models, based on throughput units or similar capacity concepts plus per-operation charges. Related services such as storage for dead-lettering, queues, functions and logging add their own costs. Prices change, so confirm on the current pricing page before budgeting.

Event-driven systems are easy to start and hard to understand once there are hundreds of subscriptions.

Habits that make event-driven systems dependable, and habits that make them fragile.

Patterns worth adopting

More anti-patterns to avoid

A review list to use before going live and at regular intervals afterward.

How organizations put Event Grid to work.

Short answers to common beginner questions.

It is a managed Azure service that routes events from sources such as Azure services and your applications to handlers that have subscribed, with filtering, retries and dead-lettering built in.

A small record stating that something happened, with an identifier, a type, a subject, a time and some details.

A topic is where events are sent. A subscription belongs to a topic and says which events go to which handler and how delivery behaves.

No. Push delivery is at least once, and order is not guaranteed, so handlers must tolerate duplicates and disorder.

Event Grid retries with increasing waits for the configured time. If it still fails, the event is dead-lettered to storage if you configured that, otherwise dropped.

Use Event Grid to announce that something happened to many listeners. Use Service Bus when a message represents work that must be processed reliably, possibly in order, by one consumer.

The classic service is built for discrete events. For continuous streams, Event Hubs is the usual choice. The newer namespace MQTT broker addresses device messaging, but check current limits and features.

In push, Event Grid calls your handler. In pull, your handler connects and fetches events at its own pace, then acknowledges them. Pull suits private or rate-limited consumers.

Usually because the endpoint did not answer the validation handshake, or the request was blocked by a firewall or gateway.

Use Microsoft Entra identities with a data sender role, restrict network access, and avoid or rotate access keys. Keep secrets out of event data.

Make handlers idempotent by recording processed event identifiers or using operations that give the same result when repeated.

Mainly per operation, with a free monthly allowance for the classic service, and capacity plus operation charges for namespace features. Downstream compute and storage often cost more. Check the current pricing page.

The concepts are stable, but features, schemas, limits, supported sources, namespace capabilities and prices change. Confirm details in the current official documentation before finalizing a design.

Event Grid is the announcement system of your cloud. Sources publish small, factual events to topics; subscriptions filter them and deliver copies to handlers such as functions, workflows, queues and web services. The system retries with backoff, saves undelivered events in a dead-letter location, and scales without servers to manage. Because delivery is at least once and unordered, handlers must be idempotent and tolerant of disorder, and fragile handlers belong behind queues. Security rests on identities, narrow roles, careful network control and small events free of sensitive data. The newer namespace features add an MQTT broker for devices and pull delivery for controlled consumers, while Service Bus and Event Hubs remain the right tools for reliable work messages and high-volume streams. Because capabilities and pricing keep evolving, hold on to the lasting ideas in this guide and verify the details in current documentation. With these habits, your systems stop polling and start listening, and they grow by adding subscribers instead of rewriting senders.