Azure Event Grid - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Azure Event Grid is the part of Azure that tells your apps what already happened. A file lands in storage, a device connects, an order comes in, and instead of your code asking over and over, Event Grid just delivers the news. Plenty of people meet it and stall because event grid, service, bus and event hubs all sound like the same thing. Welcome to the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. Today, we walk through Azure Event Grid in plain English, and we settle where it belongs next to the other two. Why Event driven keeps coming up. Think about how most software checks for change. It asks the same question on a timer over and over, waiting for something to be different.

0:41 A service wakes up every minute, checks the database, finds nothing new, and goes back to sleep. That works. But you pay for every one of those empty checks, and your app always sits a little behind the truth. Event driven design flips that around. Instead of asking whether something changed, your app gets told. The moment it happens, you stop watching the door and start listening for a knock. In a busy system, that difference shows up fast. Polling every minute across a dozen services adds up, and each check costs a little money and a little time, while the change you actually care about waits for the next sweep to notice it. It helps to be clear about what counts as an event. An event is the smallest piece of information that fully describes something that happened in a system. Every event carries a few basics like where it came from, when it happened, and a unique ID along with the details that matter for that specific thing.

1:27 In Azure, that could be a file landing in a storage account, which is really just a place your files live in the cloud. It could be a device connecting to IoT hub or an order arriving in an app you built yourself. The event itself is small, maybe a few lines of text, but it holds enough to tell your code that something just changed. Here's the part to hold on to. An event doesn't do any work. It carries news and somewhere else, a piece of code reads that news and decides what to do next. That separation is what lets event driven systems grow. Because the thing that announces a change and the thing that reacts to it, never have to be the same piece of software. Once you see events that way, the missing piece becomes obvious. Something has to catch all of this news and pass it to the right place. And that job belongs to Azure Event Grid. What Azure Event Grid actually is that job catching events and passing them along is exactly what Azure Event Grid does.

2:12 It's a fully managed publish subscribe service for distributing messages, and Microsoft built it for event driven apps. Fully managed means you don't run servers for it. You create a few resources and Azure keeps the service running and scaling behind the scenes. If you want a picture for it, think of a post office publishers drop off news event grid sorts it, and subscribers get exactly the items they signed up for. Nobody needs to know everyone else's address because the sorting office handles the handoff. Events come in through two doors. Apps and services usually send them over HTTP, which is the same language your browser uses to talk to websites. Devices like sensors on a factory floor can send them over Mqtt, a lightweight protocol built for small messages and flaky connections.

2:53 For a first look, you only need to know that both doors lead into the same sorting office. There's a shared language underneath. Two event grid supports cloud events, an open standard for describing events, so a system built by one team can hand an event to a system built by another and have it make sense. That matters more than it sounds, because standards are what stop every integration from turning into a custom translation job. It also scales without you thinking about it. You don't size servers or guess at capacity because the service handles that. As your events grow, which is the kind of chore you only notice once you've had to do it by hand. Say this part early because it saves confusion later. Event grid is a delivery service, not a place where your business logic lives. Its only job is to carry events from the systems that produce them to the systems that consume them.

3:35 The four words you need to use event grid. You only need four words. Once these click, most of the documentation stops feeling like a foreign language. The first is event, which we've already met. It's the record that something happened with a source, a time, and a unique ID. The second is publisher. A publisher is the application that sends the event to event grid, and the event source is the place where it actually happened. Often they're the same system. A storage account publishes an event when a file arrives, and it's also the source of that event. So the two words point at nearly the same thing. The third is topic. A topic is the channel that holds related events and you publish into it. You'll usually make one topic for a group of related events, so everything about your orders goes into one place and everything about your files goes into another. The fourth is event subscription and this one does the real work.

4:17 A subscription is your instruction to event grid saying which events on that topic you care about and where to send them. Filtering lives here too, because a subscription can pick events by type or by subject. So a handler for invoices can listen only for files that land in one folder. Then there's the handler, which is simply where the event lands. A handler can be a webhook, which is just a URL that accepts a request or an Azure service like functions, event hubs, service bus, or a storage queue. One example shows how the words connect, so follow a single file from start to finish. A file arrives in a storage account, so the storage service publishes a blob created event to a topic. A subscription on that topic is set up to accept only blob created events, so it ignores everything else that subscription points at an Azure function and the function wakes up, reads the event, and does whatever you told it to do with that file.

5:01 That's four words and one clean chain. Notice the split between topic and subscription. One topic can feed many subscriptions, so the same event can reach a database writer, a notification service, and an audit log all at once. The publisher never has to know how many things care about its news, and each subscriber gets to choose what it listens for. These same words show up in event systems well beyond Azure, so learning them here carries over to almost any event driven tool you touch. Before we move on, there's one thing to flag because it changes how you work with all of this. Three kinds of topics. Here's the twist I mentioned. You don't always build the topic yourself because Azure ships some of them ready to go. System topics are built in topics that represent events published by Azure Services. If you want to react to files in the storage account, messages in event hubs or keys in Key Vault, a system topic already knows how to announce those changes.

5:50 More than twenty Azure services support this, which covers a huge share of the events a beginner will ever care about. One detail surprises people. Only Azure services can publish to a system topic, so there's no endpoint and no access key for you to publish with. You don't publish into a system topic, you subscribe to it and let Azure do the announcing system. Topics also come with a small bonus because Azure manages them. You can set up monitoring and alerts on publishing and delivery failures without building any of that yourself. Custom topics are the ones you create for your own applications. A custom topic is its own resource with its own endpoint, so your app can publish events into it and anything else can subscribe. If you're building something and you want other parts of your system to react to it, this is the door you'll use. Partner topics handle a third case events that come from outside Microsoft through a feature called partner Events.

6:35 Providers like Auth0 and Microsoft Graph can publish their events into Event Grid, and you subscribe to them the same way you'd subscribe to anything else between the three. The pattern is simple system topics come from Azure. Custom topics come from your code and partner topics come from outside providers. All three end in the same place. An event subscription that decides where the events go. In practice, you often build nothing at all. You find the system topic that's already broadcasting the change you care about. Point a subscription at your handler and move on. Push or pull. Now that events are flowing, the next decision is how they reach your app, and event grid gives you two answers. Push delivery is the default way to think about it. You define a destination in an event subscription. An event grid sends events to that destination as they arrive.

7:18 This is what you want most of the time because it kills the polling we talked about earlier. You stop asking and start receiving pull. Delivery works the other way. Instead of event grid sending events to you, your application connects to event grid and reads events. When it's ready, the app grabs a batch, acknowledges the ones it finished, and can release the rest back for later. It's the difference between mail pushed through your door and a mailbox you check on your own schedule so each mode has a natural fit. Pushes the pick when your app can receive a request at an endpoint and you want the news. The moment something changes, pull suits you better. When your app isn't always running. When you only want to process events at certain times, or when you need private networking. Private links which keep traffic off the public internet. Work with pull delivery and not with push pull delivery has one more advantage.

7:59 Because consumers connect to event grid, you can add more of them to read faster, so a single subscription can serve one small app or a whole fleet of them. One catch matters here pull delivery works with topics inside an event grid namespace, which is a newer resource model. So it's a slightly different setup than the custom and system topics we just covered. If you're starting out and your app can expose an endpoint, push is usually the simpler path. When you're unsure there's a quick test. Ask whether your app can accept a request at any moment. If it can push fits, if it can't, or if you want. The control pull is the answer. When delivery fails. Retries and dead lettering. The worry almost every beginner has is a fair one, and it's about what happens when a handler is down at the exact moment an event shows up.

8:40 It's natural to assume the event just vanishes. The short answer is no, and that reliability is a big reason people pick event grid. Event grid delivers at least once and it keeps trying. When something goes wrong, it waits 30s for a response from your handler, and if nothing comes back, it treats that delivery as a failure and queues the event for another try. The retries don't all happen at once. They slow down over time like knocks on a door that get further apart. Event grid tries again after 10s, then 30s, then a minute, then five minutes, then ten, then thirty minutes, then an hour, then three hours, then six, and finally every twelve hours up to a full day. You can tune two dials on this behavior. The first is the maximum number of attempts, which you can set anywhere from one to thirty, and it defaults to thirty.

9:20 The second is the time to live, which is how long an event stays eligible for delivery, set between one and one thousand four hundred and forty minutes, and it also defaults to twenty four hours. Whichever limit arrives first stops the delivery. One detail matters here only a narrow set of responses counts as success. The codes two hundred through two hundred and four. Anything outside that range is a failure and gets retried. Some failures aren't worth retrying at all. A bad request, a payload that's too large or a forbidden response will never succeed. So Event Grid skips the retries and moves straight to the next decision. By default, that decision is to drop the event, which is why the last piece matters. Dead lettering is the safety net. It's off unless you turn it on, and when you turn it on, you point it at a storage container. Any event that can't be delivered gets parked there instead of disappearing.

10:02 So you can open it up later, see what went wrong and replay it. Once your handler is healthy. Again, that safety net comes with a small delay of about five minutes before the event lands in and storage. If the container is missing for hours, the event is dropped, so set it up before you rely on it. Two honest caveats come with this setup. Event grid doesn't promise events arrive in order, so a later event can show up before an earlier one, and at least once. Delivery means your handler might see the same event twice, so it's smart to make handlers safe to run more than once. The takeaway is simple you get retries for free. You can add a safety net for the heart failures, and you design your handler so a duplicate event doesn't break anything. Event grid versus service bus versus event hubs. With all of that in place, we can finally answer the question that trips up almost everyone because these three services get mentioned together so often that they start to blur.

10:49 The way to keep them apart is to stop thinking of them as three versions of one service. There are three different jobs, and each one is very good at its own job. Azure Event Grid does reactive event routing. Its whole purpose is to react to a status change, and it deals in events which are discrete notifications. You reach for event grid when something happened and you want the right code to respond, especially in serverless setups where you'd rather not manage servers. Azure Event hubs does big data streaming and ingestion. It deals in event streams, which are time ordered series of events, and it's built to take in millions of events per second. Event hubs earns its place when you have a firehose of telemetry logs or sensor readings that you want to analyze in real time or store for later. Then there's Azure Service Bus, which does enterprise transactional messaging.

11:31 It deals in messages which are higher value payloads, and it's built for order processing, financial transactions, and workflows where a lost message is not acceptable. Service bus is the tool when the work itself has to be processed reliably, and a notification alone isn't enough. The differences show up in the details. Event grid makes no ordering guarantee, and service bus can keep first in first out order using sessions while event hubs orders events within a partition. Transactions and duplicate detection are service bus features and capture and replay. The ability to rewind and reprocess a stream belongs to event hubs. Dead lettering exists in event grid and Service Bus, but not in event hubs. They even speak different languages under the hood, event grid uses HTTP and Mqtt, event hubs, speaks Kafka and HTTP and service bus speaks HTTP two.

12:14 You rarely pick a service by protocol, but it explains why a tool built for Kafka slots into event hubs so cleanly. The most useful thing to hear is that these services aren't competitors. They're designed to sit side by side. Microsoft's own example is an online store that uses service Bus to process orders. Event hubs to capture site telemetry and event grid to react to events like an item being shipped. That's three services, three jobs, and one system. The services even feed each other. A subscription can send events straight into event hubs or service bus. So Event grid often becomes the front door that hands work to the service built for it. So the next time someone says event driven and lists all three, you can place them. Event grid announces event hubs, streams, and service bus delivers work that has to be handled.

12:54 A simple picture to keep. Here's one picture that ties it together. A file lands in a storage account and Azure Storage publishes an event. A system topic holds that event a subscription filters for blob created and an Azure function picks it up and does the work. Read that chain again and notice what event grid did and didn't do. It carried the news that something happened and it never touched the file itself. That's the whole role. Event grid. Moves events from where they happen to where they're needed, and then it steps aside. That chain is the pattern to remember, because almost every event grid setup looks like some version of it. The names change and the handler changes, but the shape stays the same. Keep the contrast close to. If you need to send work that must be processed reliably, that's service bus. If you're streaming high volume data to analyze later, that's event hubs.

13:37 And if you simply need the right code to react when something changes, that's event grid recap. And one question. So here's where we land. Azure Event grid is the routing layer that carries news of change topics. Hold those events subscriptions. Choose which ones you care about, and handlers do the reacting when delivery fails. Retries and dead lettering keep the events from disappearing. Before you go, sit with one question. Look at the work you do today and find one thing you keep checking on a schedule just in case something moved. What would your week look like if something simply told you the moment it happened? Instead of you going to look? If you want to keep mastering the tools and the mindset shaping the future of work, subscribe to M365 FM. Thanks for listening.