July 15, 2026
Event Grid - Simply Explained
Modern cloud applications need to react instantly when something happens. A file is uploaded, a virtual machine is created, or an order is placed—and the right services should respond automatically without constantly checking for changes. In this episode of m365.fm, we explain Azure Event Grid in plain English, showing how it enables event-driven architectures that are faster, more efficient, and easier to scale than traditional polling-based systems. Through simple real-world examples and an easy-to-understand smart home analogy, you'll learn how Event Grid helps Azure services communicate automatically while reducing unnecessary compute, network traffic, and operational complexity.
WHY POLLING IS HOLDING YOUR APPLICATIONS BACK
Many applications still rely on polling, repeatedly asking whether something has changed even when nothing has happened. This creates unnecessary CPU usage, network traffic, and cloud costs while introducing delays between an event occurring and an application responding. We explain why event-driven architectures solve this problem by replacing constant requests with intelligent notifications. Instead of repeatedly checking for updates, applications simply wait until Event Grid tells them something important has happened, creating faster, more responsive, and significantly more efficient systems.
EVENTS, TOPICS, AND SUBSCRIPTIONS EXPLAINED
Understanding Event Grid starts with understanding its core building blocks. Learn the difference between events, topics, subscriptions, and event handlers, and discover how Azure services publish lightweight notifications that are automatically routed to the right destinations. We explain System Topics, Custom Topics, Azure Functions, Logic Apps, Webhooks, Storage Queues, and fan-out scenarios where a single event can trigger multiple automated workflows simultaneously. By separating publishers from subscribers, Event Grid creates loosely coupled applications that are easier to maintain, extend, and scale.
FILTERING, RELIABILITY, AND EVENT DELIVERY
Not every service needs every event. This episode explores Event Grid's powerful filtering capabilities, allowing subscriptions to receive only the notifications they actually need based on event type, resource path, prefixes, suffixes, or custom properties. We also cover enterprise-grade reliability features including automatic retries, exponential backoff, dead-lettering, and failure handling. You'll learn how Event Grid ensures important business events aren't silently lost while giving administrators complete visibility into failed deliveries and processing issues.
EVENT GRID VS. EVENT HUBS VS. SERVICE BUS
Azure offers several messaging services, and understanding when to use each one is critical. We compare Event Grid, Event Hubs, and Azure Service Bus, explaining the unique role each service plays within modern cloud architectures. Discover why Event Grid is designed for event notifications and serverless automation, Event Hubs excels at high-throughput telemetry and streaming workloads, and Service Bus provides reliable enterprise messaging with guaranteed delivery and ordered processing. Whether you're building cloud-native applications, automating Azure resources, or designing enterprise integration solutions, this episode provides the practical knowledge you need to choose the right Azure messaging service for every scenario.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:03,400
Welcome to another episode of Microsoft Knowledge Nuggets here on M365.
2
00:00:03,400 --> 00:00:05,040
FM, I'm your host, Milco Peters.
3
00:00:05,040 --> 00:00:07,680
Today's topic is one that almost everyone in Azure has heard of,
4
00:00:07,680 --> 00:00:09,960
but few people can actually explain in plain English.
5
00:00:09,960 --> 00:00:11,000
It's as your event grid.
6
00:00:11,000 --> 00:00:12,280
So what exactly is event grid?
7
00:00:12,280 --> 00:00:15,560
Is it just another messaging service or is it something completely different?
8
00:00:15,560 --> 00:00:18,760
By the end of this episode, you'll understand what event grid actually is,
9
00:00:18,760 --> 00:00:23,720
why event-driven architecture matters and how to think about it using a simple smart home analogy.
10
00:00:23,720 --> 00:00:28,800
Imagine your phone didn't have push notifications and had to wake up every two seconds to ask the email server,
11
00:00:28,800 --> 00:00:30,080
do I have any new emails?
12
00:00:30,080 --> 00:00:32,200
Then it gets a response, no.
13
00:00:32,200 --> 00:00:35,680
Two seconds later it asks again and gets another no, all day long.
14
00:00:35,680 --> 00:00:39,040
That's wasted battery, wasted bandwidth and wasted time.
15
00:00:39,040 --> 00:00:41,320
And most software systems still work this way.
16
00:00:41,320 --> 00:00:43,640
There's a smarter approach instead of constantly asking,
17
00:00:43,640 --> 00:00:46,040
"You wait to be told, that's exactly what event grid enables,
18
00:00:46,040 --> 00:00:48,840
you'll see how Azure services can talk to each other automatically,
19
00:00:48,840 --> 00:00:51,680
without any manual intervention or wasteful polling."
20
00:00:51,680 --> 00:00:54,760
The problem, why polling is wasting your time?
21
00:00:54,760 --> 00:00:56,320
Let's start with the problem.
22
00:00:56,320 --> 00:01:00,120
Most software systems today communicate using something called polling.
23
00:01:00,120 --> 00:01:02,000
Polling is exactly what it sounds like.
24
00:01:02,000 --> 00:01:06,080
One server keeps asking another server, "Hey, anything new yet?"
25
00:01:06,080 --> 00:01:07,800
Over and over.
26
00:01:07,800 --> 00:01:09,040
Here's a real world example.
27
00:01:09,040 --> 00:01:13,200
Imagine you wrote a script that checks a folder on your server every 30 seconds for new files.
28
00:01:13,200 --> 00:01:18,040
Maybe it's looking for incoming invoices, new photos or reports from another system.
29
00:01:18,040 --> 00:01:22,000
Every 30 seconds the script wakes up, opens the folder, looks at every file,
30
00:01:22,000 --> 00:01:24,360
checks if anything changed and then goes back to sleep.
31
00:01:24,360 --> 00:01:26,720
30 seconds later, it does it all over again.
32
00:01:26,720 --> 00:01:28,440
Now what happens most of the time?
33
00:01:28,440 --> 00:01:29,040
Nothing.
34
00:01:29,040 --> 00:01:33,600
No new files, so the script just checked an empty folder and wasted a tiny bit of compute in bandwidth.
35
00:01:33,600 --> 00:01:39,360
But here's the thing, multiply that by 10 scripts or 100 or 1000 services all polling each other.
36
00:01:39,360 --> 00:01:44,240
Suddenly you're burning CPU cycles, network traffic and electricity on checks that return nothing useful.
37
00:01:44,240 --> 00:01:47,440
The inefficiency is staggering because most polling checks return nothing.
38
00:01:47,440 --> 00:01:51,520
You're paying for compute in bandwidth to ask questions you already know the answer to.
39
00:01:51,520 --> 00:01:55,920
And the worst part is the more responsive you want your system to be, the more often you have to poll.
40
00:01:55,920 --> 00:02:02,080
Want near real-time reactions, you need to check every second, which means 86,400 empty checks per day for nothing.
41
00:02:02,080 --> 00:02:04,520
Now contrast that with an event-driven approach.
42
00:02:04,520 --> 00:02:09,920
Instead of asking anything new over and over, you simply say, "Tell me when something happens.
43
00:02:09,920 --> 00:02:11,320
Don't make me keep asking."
44
00:02:11,320 --> 00:02:16,040
It's like the difference between refreshing your inbox every two seconds and getting a push notification.
45
00:02:16,040 --> 00:02:18,160
One is constant work, the other is waiting to be told.
46
00:02:18,160 --> 00:02:20,600
So if polling is wasteful, what's the better way?
47
00:02:20,600 --> 00:02:22,400
That's where Event Grid comes in.
48
00:02:22,400 --> 00:02:24,400
What is Event Grid, the Smart Home Hub?
49
00:02:24,400 --> 00:02:25,720
Today's topic is Event Grid.
50
00:02:25,720 --> 00:02:26,640
What exactly is it?
51
00:02:26,640 --> 00:02:28,280
Is it just another Azure service?
52
00:02:28,280 --> 00:02:29,960
Or is it something much bigger?
53
00:02:29,960 --> 00:02:31,400
Here's the simplest definition.
54
00:02:31,400 --> 00:02:34,160
Event Grid is a fully managed event-rooting service in Azure.
55
00:02:34,160 --> 00:02:36,280
That's a mouthful, so let me say it in plain English.
56
00:02:36,280 --> 00:02:38,760
Think of Event Grid as the central hub in a Smart Home.
57
00:02:38,760 --> 00:02:43,680
In a Smart Home you have sensors everywhere, motion sensors in the hallway, door sensors on the front door,
58
00:02:43,680 --> 00:02:45,360
temperature sensors in the living room.
59
00:02:45,360 --> 00:02:49,560
Now imagine if each sensor had to talk directly to every device it needed to trigger.
60
00:02:49,560 --> 00:02:53,720
Your motion sensor would need to know about the hallway lights, the alarm system and the thermostat.
61
00:02:53,720 --> 00:02:58,000
The door sensor would need to know about the doorbell, the security camera and the welcome matte light.
62
00:02:58,000 --> 00:02:58,800
That's a mess.
63
00:02:58,800 --> 00:03:01,680
Every time you add a new device, you'd have to rewire everything.
64
00:03:01,680 --> 00:03:04,800
But in a real Smart Home, all those sensors talk to a central hub.
65
00:03:04,800 --> 00:03:07,800
The motion sensor just says "I detected motion."
66
00:03:07,800 --> 00:03:10,120
It doesn't know or care what happens next.
67
00:03:10,120 --> 00:03:11,080
The hub decides.
68
00:03:11,080 --> 00:03:14,120
It turns on the lights, triggers the alarm, and adjusts the thermostat.
69
00:03:14,120 --> 00:03:15,560
The sensor doesn't know who's listening.
70
00:03:15,560 --> 00:03:17,400
The lights don't know who triggered them.
71
00:03:17,400 --> 00:03:18,480
They just trust the hub.
72
00:03:18,480 --> 00:03:21,600
That's exactly what Event Grid does for your Azure services.
73
00:03:21,600 --> 00:03:25,520
When a file is uploaded to blob storage, it doesn't need to know which service should process it.
74
00:03:25,520 --> 00:03:27,560
It just publishes an event to Event Grid.
75
00:03:27,560 --> 00:03:30,400
Then Event Grid routes that event to whatever services are listening.
76
00:03:30,400 --> 00:03:36,000
There's maybe an Azure function that generates a thumbnail, a logic app that sends a notification,
77
00:03:36,000 --> 00:03:39,160
and a storage queue that archives the event.
78
00:03:39,160 --> 00:03:42,840
The publisher doesn't know the subscribers and the subscribers don't know the publisher.
79
00:03:42,840 --> 00:03:45,520
They just trust Event Grid to route the message correctly.
80
00:03:45,520 --> 00:03:49,600
And the pricing model, its paper event, the first 100,000 operations each month are free.
81
00:03:49,600 --> 00:03:53,080
So for most small to medium workloads, it costs essentially nothing.
82
00:03:53,080 --> 00:03:54,680
You're not paying for idle infrastructure.
83
00:03:54,680 --> 00:03:56,960
You're only paying when something actually happens.
84
00:03:56,960 --> 00:03:59,480
Now let's break down the pieces that make this work.
85
00:03:59,480 --> 00:04:03,880
Because Event Grid isn't just one thing, it's a collection of building blocks that work together.
86
00:04:03,880 --> 00:04:05,480
The building blocks events.
87
00:04:05,480 --> 00:04:07,200
Let's start with the most basic piece.
88
00:04:07,200 --> 00:04:08,200
The event itself.
89
00:04:08,200 --> 00:04:10,640
An event is simply a notification that something happened.
90
00:04:10,640 --> 00:04:12,240
That's it. It's not the data itself.
91
00:04:12,240 --> 00:04:15,240
It's a signal that says, "Hey, this thing just occurred."
92
00:04:15,240 --> 00:04:16,520
Think of it like a doorbell.
93
00:04:16,520 --> 00:04:19,120
When someone rings your doorbell, you know someone is at the door.
94
00:04:19,120 --> 00:04:22,160
But the doorbell doesn't tell you who it is, why they're there or what they want.
95
00:04:22,160 --> 00:04:23,880
It just tells you someone is there.
96
00:04:23,880 --> 00:04:25,360
You have to go look for yourself.
97
00:04:25,360 --> 00:04:26,520
Events work the same way.
98
00:04:26,520 --> 00:04:30,760
A blob created event tells you that a file was uploaded to a storage container.
99
00:04:30,760 --> 00:04:32,320
But it doesn't contain the file itself.
100
00:04:32,320 --> 00:04:34,440
It just says, "A file was uploaded."
101
00:04:34,440 --> 00:04:35,440
Here's the name.
102
00:04:35,440 --> 00:04:36,440
Here's when it happened.
103
00:04:36,440 --> 00:04:37,800
Go check it out if you need to.
104
00:04:37,800 --> 00:04:41,360
Now when Event Grid sends an event, it follows a specific format.
105
00:04:41,360 --> 00:04:43,360
You get a few key pieces of information.
106
00:04:43,360 --> 00:04:44,960
The event type tells you what happened.
107
00:04:44,960 --> 00:04:49,040
What could be blob created or blob deleted or resource write success.
108
00:04:49,040 --> 00:04:51,120
The subject tells you what resource it happened to.
109
00:04:51,120 --> 00:04:53,520
That's the exact path to the file or the resource ID.
110
00:04:53,520 --> 00:04:55,280
The event time tells you when it happened.
111
00:04:55,280 --> 00:04:58,160
An ID is a unique identifier for that specific event.
112
00:04:58,160 --> 00:05:02,680
And a small data field contains a few extra details like the file size or the URL to the blob.
113
00:05:02,680 --> 00:05:04,000
Notice I said, "Small data field."
114
00:05:04,000 --> 00:05:05,000
That's important.
115
00:05:05,000 --> 00:05:06,000
Events are lightweight.
116
00:05:06,000 --> 00:05:09,680
They carry just enough information to tell you something happened and where to look.
117
00:05:09,680 --> 00:05:11,200
They don't carry the full payload.
118
00:05:11,200 --> 00:05:13,000
If you need the actual file, you go get it.
119
00:05:13,000 --> 00:05:14,640
The event just points you in the right direction.
120
00:05:14,640 --> 00:05:17,040
This is a key difference between an event and a message.
121
00:05:17,040 --> 00:05:18,560
A message carries a payload.
122
00:05:18,560 --> 00:05:20,000
It's like a letter in an envelope.
123
00:05:20,000 --> 00:05:21,920
The letter contains the actual content.
124
00:05:21,920 --> 00:05:23,400
An event is more like a postcard.
125
00:05:23,400 --> 00:05:24,400
It says, "I'm here.
126
00:05:24,400 --> 00:05:25,880
Come find me."
127
00:05:25,880 --> 00:05:27,360
Events are notifications.
128
00:05:27,360 --> 00:05:28,760
Messages are deliveries.
129
00:05:28,760 --> 00:05:30,080
So events are the signals.
130
00:05:30,080 --> 00:05:31,320
There is something happened.
131
00:05:31,320 --> 00:05:32,320
Announcements.
132
00:05:32,320 --> 00:05:33,400
But where do they actually go?
133
00:05:33,400 --> 00:05:36,040
They don't just float around in the cloud hoping someone picks them up.
134
00:05:36,040 --> 00:05:37,680
They go to a topic.
135
00:05:37,680 --> 00:05:38,680
Topics.
136
00:05:38,680 --> 00:05:39,680
Where events get published.
137
00:05:39,680 --> 00:05:40,680
What exactly is a topic?
138
00:05:40,680 --> 00:05:43,000
Think of it as a mailbox for notifications.
139
00:05:43,000 --> 00:05:46,560
Messages send their events to a topic and the topic holds them until they're routed to the
140
00:05:46,560 --> 00:05:47,560
right place.
141
00:05:47,560 --> 00:05:48,560
Simple as that.
142
00:05:48,560 --> 00:05:51,120
Now, there are two types of topics in Event Grid.
143
00:05:51,120 --> 00:05:52,440
System topics and custom topics.
144
00:05:52,440 --> 00:05:53,640
Let's break them down.
145
00:05:53,640 --> 00:05:55,760
System topics are built in for Azure services.
146
00:05:55,760 --> 00:05:59,880
When you create a storage account, Event Grid automatically creates a system topic for it.
147
00:05:59,880 --> 00:06:01,360
You don't have to do anything.
148
00:06:01,360 --> 00:06:03,040
The events are already available.
149
00:06:03,040 --> 00:06:04,600
You can subscribe to them right away.
150
00:06:04,600 --> 00:06:08,120
Same with Azure Resource Manager, Event Hubs and many other services.
151
00:06:08,120 --> 00:06:09,440
These are the plug and play topics.
152
00:06:09,440 --> 00:06:10,440
They just work.
153
00:06:10,440 --> 00:06:11,680
No setup needed.
154
00:06:11,680 --> 00:06:13,640
Some topics are for your own applications.
155
00:06:13,640 --> 00:06:15,840
Let's say you build a custom ordering system.
156
00:06:15,840 --> 00:06:18,360
You want to publish events when an order is placed.
157
00:06:18,360 --> 00:06:21,960
So you create a custom topic and your application sends events to it.
158
00:06:21,960 --> 00:06:24,640
Then any subscriber can listen for those events and react accordingly.
159
00:06:24,640 --> 00:06:25,640
You control the topic.
160
00:06:25,640 --> 00:06:26,640
You control the events.
161
00:06:26,640 --> 00:06:28,560
Here's a smart home way to think about it.
162
00:06:28,560 --> 00:06:30,200
Topics are like channels on a radio.
163
00:06:30,200 --> 00:06:34,720
You have a motion alerts channel, a temperature changes channel, a door open channel.
164
00:06:34,720 --> 00:06:36,600
Senses published to the appropriate channel.
165
00:06:36,600 --> 00:06:38,120
Subscribers tune into the channels they care about.
166
00:06:38,120 --> 00:06:40,800
The motion sensor doesn't publish to the temperature channel.
167
00:06:40,800 --> 00:06:45,040
It publishes to the motion channel and only subscribers who care about motion listen there.
168
00:06:45,040 --> 00:06:46,040
So events go to topics.
169
00:06:46,040 --> 00:06:47,480
The topic is the mailbox.
170
00:06:47,480 --> 00:06:49,400
But a mailbox is useless if nobody checks it.
171
00:06:49,400 --> 00:06:50,400
So who's listening?
172
00:06:50,400 --> 00:06:51,840
That's the big question.
173
00:06:51,840 --> 00:06:53,600
Subscriptions and handlers who gets the news.
174
00:06:53,600 --> 00:06:54,600
So who's listening?
175
00:06:54,600 --> 00:06:56,280
That's where subscriptions and handlers come in.
176
00:06:56,280 --> 00:06:57,280
Let me explain.
177
00:06:57,280 --> 00:06:58,280
A subscription is a rule.
178
00:06:58,280 --> 00:07:01,520
It says send this topic's events to the specific destination.
179
00:07:01,520 --> 00:07:05,160
You create a subscription on a topic and you tell it where you want the events to go.
180
00:07:05,160 --> 00:07:07,200
That destination is called an event handler.
181
00:07:07,200 --> 00:07:10,560
Event handlers are the services that actually receive and process the events.
182
00:07:10,560 --> 00:07:11,880
They're the ones that do the work.
183
00:07:11,880 --> 00:07:14,360
An event grid supports a wide range of them.
184
00:07:14,360 --> 00:07:16,200
Let's go through the most common ones.
185
00:07:16,200 --> 00:07:18,240
Azure functions are probably the most popular.
186
00:07:18,240 --> 00:07:22,240
You write a small piece of code and when an event arrives, the function runs.
187
00:07:22,240 --> 00:07:23,520
No service to manage.
188
00:07:23,520 --> 00:07:25,120
Logic apps are another common choice.
189
00:07:25,120 --> 00:07:28,200
They let you build visual workflows without writing code.
190
00:07:28,200 --> 00:07:29,440
Great for automation.
191
00:07:29,440 --> 00:07:33,640
Web hooks let you send events to any HTTP endpoint even outside of Azure.
192
00:07:33,640 --> 00:07:36,960
And then you have storage queues and service bus which are useful when you want to buffer
193
00:07:36,960 --> 00:07:39,000
events for later processing.
194
00:07:39,000 --> 00:07:40,520
Now here's where it gets powerful.
195
00:07:40,520 --> 00:07:43,320
An event can trigger multiple handlers in parallel.
196
00:07:43,320 --> 00:07:44,880
This is called the fan out pattern.
197
00:07:44,880 --> 00:07:47,000
Let me explain with the smart home analogy.
198
00:07:47,000 --> 00:07:48,440
Imagine you arrive home.
199
00:07:48,440 --> 00:07:50,000
You walk through the front door.
200
00:07:50,000 --> 00:07:53,240
That single action arriving home could trigger multiple things.
201
00:07:53,240 --> 00:07:54,440
The whole way lights turn on.
202
00:07:54,440 --> 00:07:56,760
The thermostat adjusts to your preferred temperature.
203
00:07:56,760 --> 00:07:58,400
The security alarm disarms.
204
00:07:58,400 --> 00:08:01,000
The coffee machine starts brewing all from one event.
205
00:08:01,000 --> 00:08:03,280
The door sensor doesn't need to know about the coffee machine.
206
00:08:03,280 --> 00:08:05,000
It just says door opened.
207
00:08:05,000 --> 00:08:06,400
The hub handles the rest.
208
00:08:06,400 --> 00:08:07,960
Event grid works the same way.
209
00:08:07,960 --> 00:08:13,000
A single blob created event can trigger an Azure function to generate a thumbnail, a logic
210
00:08:13,000 --> 00:08:17,000
app to send a notification to your team and a storage queue to archive the event for later
211
00:08:17,000 --> 00:08:20,040
auditing all at the same time all from one event.
212
00:08:20,040 --> 00:08:21,600
The publisher doesn't know about any of them.
213
00:08:21,600 --> 00:08:24,120
It just published the event and event grid handled the routing.
214
00:08:24,120 --> 00:08:25,120
That's the magic of it.
215
00:08:25,120 --> 00:08:26,120
But here's a question.
216
00:08:26,120 --> 00:08:28,960
What if you don't want every handler to get every event?
217
00:08:28,960 --> 00:08:31,680
What if you only want certain events to reach certain handlers?
218
00:08:31,680 --> 00:08:33,120
That's where filtering comes in.
219
00:08:33,120 --> 00:08:35,520
But we'll cover that in another episode.
220
00:08:35,520 --> 00:08:37,920
Filtering only the events you care about.
221
00:08:37,920 --> 00:08:39,520
So what happens without filtering?
222
00:08:39,520 --> 00:08:42,600
Every subscription receives every single event published to that topic.
223
00:08:42,600 --> 00:08:44,080
It gets noisy and wasteful fast.
224
00:08:44,080 --> 00:08:47,400
Imagine your motion sensor triggers every time your cat walks by.
225
00:08:47,400 --> 00:08:50,640
You'd get a notification every few minutes and pretty soon you'd just ignore them.
226
00:08:50,640 --> 00:08:52,400
That's the problem with unfiltered events.
227
00:08:52,400 --> 00:08:55,120
Event grid gives you a way to filter those events.
228
00:08:55,120 --> 00:08:58,560
So each subscription only gets the ones it actually cares about.
229
00:08:58,560 --> 00:09:02,160
You can filter on the event type, the subject path, or even specific data fields inside the
230
00:09:02,160 --> 00:09:03,160
event.
231
00:09:03,160 --> 00:09:04,160
The idea is simple.
232
00:09:04,160 --> 00:09:05,400
Only deliver what matters.
233
00:09:05,400 --> 00:09:06,400
Here's a real example.
234
00:09:06,400 --> 00:09:09,120
Say you have a storage account with multiple containers.
235
00:09:09,120 --> 00:09:12,540
One holds invoices, another holds photos, and another holds logs.
236
00:09:12,540 --> 00:09:16,020
You want to trigger a process only when a new invoice shows up, not when a photo or log
237
00:09:16,020 --> 00:09:17,020
file appears.
238
00:09:17,020 --> 00:09:19,200
So you set up a filter on the subject field.
239
00:09:19,200 --> 00:09:21,400
The subject contains the full path to the blob.
240
00:09:21,400 --> 00:09:25,680
You tell event grid to only match subjects that start with, push, blob services, default
241
00:09:25,680 --> 00:09:27,280
or containers invoices.
242
00:09:27,280 --> 00:09:30,960
Now only files uploaded to that invoices container trigger your handler.
243
00:09:30,960 --> 00:09:32,680
Photos and logs are ignored completely.
244
00:09:32,680 --> 00:09:35,000
You can also use prefix and suffix filtering.
245
00:09:35,000 --> 00:09:40,640
Maybe you only want to trigger on files ending with post PDF or files that start with urgent.
246
00:09:40,640 --> 00:09:44,000
Event grid gives you that control without any extra code.
247
00:09:44,000 --> 00:09:45,720
Let's go back to the smart home analogy.
248
00:09:45,720 --> 00:09:47,720
You don't want your bedroom lights to turn on.
249
00:09:47,720 --> 00:09:49,840
Every time motion is detected anywhere in the house.
250
00:09:49,840 --> 00:09:53,760
You only want them on when motion happens in the bedroom and maybe only after sunset.
251
00:09:53,760 --> 00:09:54,760
That's filtering.
252
00:09:54,760 --> 00:09:58,160
It's about making sure the right events reach the right handlers and nothing else.
253
00:09:58,160 --> 00:10:00,600
So events are filtered and sent to the right handlers.
254
00:10:00,600 --> 00:10:01,600
That sounds great.
255
00:10:01,600 --> 00:10:03,200
But what happens when something goes wrong?
256
00:10:03,200 --> 00:10:04,280
What if the handler is down?
257
00:10:04,280 --> 00:10:06,040
What if the network fails?
258
00:10:06,040 --> 00:10:09,120
Reliability, retries and dead lettering.
259
00:10:09,120 --> 00:10:11,320
So events are filtered and sent to the right handlers.
260
00:10:11,320 --> 00:10:12,320
That sounds great.
261
00:10:12,320 --> 00:10:13,880
But what happens when something goes wrong?
262
00:10:13,880 --> 00:10:15,040
What if the handler is down?
263
00:10:15,040 --> 00:10:16,280
What if the network fails?
264
00:10:16,280 --> 00:10:18,200
Event grid handles this with retries.
265
00:10:18,200 --> 00:10:22,160
If a handler doesn't respond, event grid doesn't just give up and lose the event.
266
00:10:22,160 --> 00:10:24,920
It tries again using something called exponential back off.
267
00:10:24,920 --> 00:10:27,760
But first retry happens quickly maybe a few seconds later.
268
00:10:27,760 --> 00:10:30,760
If that fails, the next retry waits a bit longer.
269
00:10:30,760 --> 00:10:31,760
Then longer.
270
00:10:31,760 --> 00:10:34,680
Event grid keeps retrying for up to 24 hours.
271
00:10:34,680 --> 00:10:37,800
That's a lot of chances for the handler to come back online.
272
00:10:37,800 --> 00:10:38,800
But here's the thing.
273
00:10:38,800 --> 00:10:41,280
What if the handler is permanently broken?
274
00:10:41,280 --> 00:10:43,880
What if someone deleted the Azure function by accident?
275
00:10:43,880 --> 00:10:47,560
What if the endpoint URL changed and nobody updated the subscription?
276
00:10:47,560 --> 00:10:50,600
After 24 hours of retries, event grid still can't deliver.
277
00:10:50,600 --> 00:10:51,840
So where does that event go?
278
00:10:51,840 --> 00:10:53,240
That's where dead lettering comes in.
279
00:10:53,240 --> 00:10:54,760
Dead lettering is your safety net.
280
00:10:54,760 --> 00:10:59,440
You configure a storage location, usually a storage queue or a blob storage container.
281
00:10:59,440 --> 00:11:03,440
If all retries fail, event grid moves the event to that dead letter location.
282
00:11:03,440 --> 00:11:04,520
It's not lost.
283
00:11:04,520 --> 00:11:07,000
It's sitting there waiting for you to investigate.
284
00:11:07,000 --> 00:11:08,240
Why does that matter?
285
00:11:08,240 --> 00:11:11,960
Because in a real system, you don't want events to disappear silently.
286
00:11:11,960 --> 00:11:16,000
Imagine a payment processing pipeline, a customer places an order, an event fires.
287
00:11:16,000 --> 00:11:18,400
The handler that processes the payment is down.
288
00:11:18,400 --> 00:11:21,040
Without retries and dead lettering, that order is just gone.
289
00:11:21,040 --> 00:11:24,600
The customer thinks they ordered something, the system has no record of it, and you never
290
00:11:24,600 --> 00:11:25,720
know it happened.
291
00:11:25,720 --> 00:11:27,560
With retries, the system keeps trying.
292
00:11:27,560 --> 00:11:30,920
With dead lettering, if it still fails, you have a record of the failure.
293
00:11:30,920 --> 00:11:33,920
You can investigate, fix the issue, and reprocess the event.
294
00:11:33,920 --> 00:11:35,720
Let's go back to the smart home analogy.
295
00:11:35,720 --> 00:11:39,760
Imagine you arrive home and the hub sends a signal to turn on the hallway light, but the
296
00:11:39,760 --> 00:11:41,120
light bulb is broken.
297
00:11:41,120 --> 00:11:42,720
The hub doesn't just give up.
298
00:11:42,720 --> 00:11:44,440
It tries again a few seconds later.
299
00:11:44,440 --> 00:11:45,440
Nothing.
300
00:11:45,440 --> 00:11:46,440
It tries again.
301
00:11:46,440 --> 00:11:47,440
Still nothing.
302
00:11:47,440 --> 00:11:49,120
After a few attempts, it logs the failure.
303
00:11:49,120 --> 00:11:51,640
You get a notification that the hallway light needs attention.
304
00:11:51,640 --> 00:11:52,840
The event isn't lost.
305
00:11:52,840 --> 00:11:53,840
It's recorded.
306
00:11:53,840 --> 00:11:55,760
You know something went wrong and you can fix it.
307
00:11:55,760 --> 00:11:56,960
That's what event grid does.
308
00:11:56,960 --> 00:11:58,320
It doesn't just fire and forget.
309
00:11:58,320 --> 00:11:59,320
It keeps trying.
310
00:11:59,320 --> 00:12:01,560
And if it can't deliver, it tells you.
311
00:12:01,560 --> 00:12:02,840
Event grid sounds great.
312
00:12:02,840 --> 00:12:04,800
But when should you use something else?
313
00:12:04,800 --> 00:12:08,120
Because not every messaging problem is an event grid problem.
314
00:12:08,120 --> 00:12:10,560
Event grid versus event hubs versus service bus.
315
00:12:10,560 --> 00:12:14,520
Azure has three main messaging services and people mix them up all the time.
316
00:12:14,520 --> 00:12:16,280
Event grid event hubs and service bus.
317
00:12:16,280 --> 00:12:19,920
They all move data around, but they solve completely different problems.
318
00:12:19,920 --> 00:12:20,920
Let's break it down.
319
00:12:20,920 --> 00:12:23,560
Event grid is for discrete events and notifications.
320
00:12:23,560 --> 00:12:25,040
Think of it as a notification bell.
321
00:12:25,040 --> 00:12:29,120
When something happens, a file gets uploaded, a VM spins up or an order is placed.
322
00:12:29,120 --> 00:12:32,440
Event grid rings that bell and tells the right handler to react immediately.
323
00:12:32,440 --> 00:12:35,640
It's built for serverless triggers, automation and fan out patterns.
324
00:12:35,640 --> 00:12:38,640
If you need to react to something, this is your tool.
325
00:12:38,640 --> 00:12:40,760
Event hubs is for high throughput streaming.
326
00:12:40,760 --> 00:12:44,760
Imagine millions of IoT devices sending data every second, or application logs, or click
327
00:12:44,760 --> 00:12:46,800
stream data from a website.
328
00:12:46,800 --> 00:12:51,400
Event hubs ingests that massive stream and makes it available for analytics pipelines.
329
00:12:51,400 --> 00:12:53,680
It's not about reacting to individual events.
330
00:12:53,680 --> 00:12:56,520
It's about collecting and processing data over time.
331
00:12:56,520 --> 00:12:59,560
Think of it as a massive pipeline, not a notification bell.
332
00:12:59,560 --> 00:13:01,120
Service bus is for reliable messaging.
333
00:13:01,120 --> 00:13:02,160
This is your mail room.
334
00:13:02,160 --> 00:13:04,440
It handles queues and topics where order matters.
335
00:13:04,440 --> 00:13:06,040
Payment processing, order fulfillment.
336
00:13:06,040 --> 00:13:09,560
Any scenario where you need guaranteed delivery first and first out ordering or transactional
337
00:13:09,560 --> 00:13:10,560
messaging.
338
00:13:10,560 --> 00:13:13,560
Service bus ensures nothing is lost in everything stays in sequence.
339
00:13:13,560 --> 00:13:15,680
It's what you use when you can't afford a mistake.
340
00:13:15,680 --> 00:13:17,200
Here's a simple rule to remember.
341
00:13:17,200 --> 00:13:18,360
Event grid reacts.
342
00:13:18,360 --> 00:13:19,960
Event hubs streams.
343
00:13:19,960 --> 00:13:21,360
Service bus coordinates.
344
00:13:21,360 --> 00:13:24,920
If you need to trigger a function when a blob is uploaded, use event grid.
345
00:13:24,920 --> 00:13:29,000
If you need to ingest millions of sensor readings per second, use event hubs.
346
00:13:29,000 --> 00:13:33,320
If you need to process orders and sequence with guaranteed delivery, use service bus.
347
00:13:33,320 --> 00:13:35,240
And here's the thing, you can use them together.
348
00:13:35,240 --> 00:13:39,000
Event grid can root events to event hubs for long term storage and analytics.
349
00:13:39,000 --> 00:13:41,360
Event hubs feeds data into stream analytics.
350
00:13:41,360 --> 00:13:43,360
Service bus queues work for downstream processing.
351
00:13:43,360 --> 00:13:45,040
They're not competitors.
352
00:13:45,040 --> 00:13:47,760
They're complimentary tools in your architecture toolbox.
353
00:13:47,760 --> 00:13:49,240
So where does that leave us?
354
00:13:49,240 --> 00:13:50,240
Let's wrap this up.
355
00:13:50,240 --> 00:13:53,560
Event grid is the smart notification hub for your Azure services.
356
00:13:53,560 --> 00:13:57,440
It replaces wasteful polling with instant event driven reactions.
357
00:13:57,440 --> 00:14:00,720
Instead of constantly asking anything new, you wait to be told.
358
00:14:00,720 --> 00:14:04,240
And when something happens, event grid roots that notification to the right handlers with
359
00:14:04,240 --> 00:14:06,760
filtering, retries and dead lettering built in.
360
00:14:06,760 --> 00:14:08,400
The key takeaway is simple.
361
00:14:08,400 --> 00:14:10,080
Move from polling to event driven.
362
00:14:10,080 --> 00:14:12,840
Stop wasting compute and bandwidth on empty checks.
363
00:14:12,840 --> 00:14:16,800
Start building reactive systems that only do work when there's actual work to do.
364
00:14:16,800 --> 00:14:17,800
Here's your challenge.
365
00:14:17,800 --> 00:14:20,160
Think of one manual check in your environment.
366
00:14:20,160 --> 00:14:24,240
In script that pulls a folder, one service that queries a database every few seconds.
367
00:14:24,240 --> 00:14:27,480
Ask yourself, could this be an event instead?
368
00:14:27,480 --> 00:14:29,640
If the answer is yes, you know where to start.
369
00:14:29,640 --> 00:14:32,240
That's it for this episode of Microsoft Knowledge Nuggets.
370
00:14:32,240 --> 00:14:35,880
If you found this helpful, subscribe on your favorite podcast platform and share this with
371
00:14:35,880 --> 00:14:37,880
someone starting there as your journey.
372
00:14:37,880 --> 00:14:40,080
I'm Mirko Peters and I'll see you in the next episode.
00:00:00,000 --> 00:00:03,400
Welcome to another episode of Microsoft Knowledge Nuggets here on M365.
2
00:00:03,400 --> 00:00:05,040
FM, I'm your host, Milco Peters.
3
00:00:05,040 --> 00:00:07,680
Today's topic is one that almost everyone in Azure has heard of,
4
00:00:07,680 --> 00:00:09,960
but few people can actually explain in plain English.
5
00:00:09,960 --> 00:00:11,000
It's as your event grid.
6
00:00:11,000 --> 00:00:12,280
So what exactly is event grid?
7
00:00:12,280 --> 00:00:15,560
Is it just another messaging service or is it something completely different?
8
00:00:15,560 --> 00:00:18,760
By the end of this episode, you'll understand what event grid actually is,
9
00:00:18,760 --> 00:00:23,720
why event-driven architecture matters and how to think about it using a simple smart home analogy.
10
00:00:23,720 --> 00:00:28,800
Imagine your phone didn't have push notifications and had to wake up every two seconds to ask the email server,
11
00:00:28,800 --> 00:00:30,080
do I have any new emails?
12
00:00:30,080 --> 00:00:32,200
Then it gets a response, no.
13
00:00:32,200 --> 00:00:35,680
Two seconds later it asks again and gets another no, all day long.
14
00:00:35,680 --> 00:00:39,040
That's wasted battery, wasted bandwidth and wasted time.
15
00:00:39,040 --> 00:00:41,320
And most software systems still work this way.
16
00:00:41,320 --> 00:00:43,640
There's a smarter approach instead of constantly asking,
17
00:00:43,640 --> 00:00:46,040
"You wait to be told, that's exactly what event grid enables,
18
00:00:46,040 --> 00:00:48,840
you'll see how Azure services can talk to each other automatically,
19
00:00:48,840 --> 00:00:51,680
without any manual intervention or wasteful polling."
20
00:00:51,680 --> 00:00:54,760
The problem, why polling is wasting your time?
21
00:00:54,760 --> 00:00:56,320
Let's start with the problem.
22
00:00:56,320 --> 00:01:00,120
Most software systems today communicate using something called polling.
23
00:01:00,120 --> 00:01:02,000
Polling is exactly what it sounds like.
24
00:01:02,000 --> 00:01:06,080
One server keeps asking another server, "Hey, anything new yet?"
25
00:01:06,080 --> 00:01:07,800
Over and over.
26
00:01:07,800 --> 00:01:09,040
Here's a real world example.
27
00:01:09,040 --> 00:01:13,200
Imagine you wrote a script that checks a folder on your server every 30 seconds for new files.
28
00:01:13,200 --> 00:01:18,040
Maybe it's looking for incoming invoices, new photos or reports from another system.
29
00:01:18,040 --> 00:01:22,000
Every 30 seconds the script wakes up, opens the folder, looks at every file,
30
00:01:22,000 --> 00:01:24,360
checks if anything changed and then goes back to sleep.
31
00:01:24,360 --> 00:01:26,720
30 seconds later, it does it all over again.
32
00:01:26,720 --> 00:01:28,440
Now what happens most of the time?
33
00:01:28,440 --> 00:01:29,040
Nothing.
34
00:01:29,040 --> 00:01:33,600
No new files, so the script just checked an empty folder and wasted a tiny bit of compute in bandwidth.
35
00:01:33,600 --> 00:01:39,360
But here's the thing, multiply that by 10 scripts or 100 or 1000 services all polling each other.
36
00:01:39,360 --> 00:01:44,240
Suddenly you're burning CPU cycles, network traffic and electricity on checks that return nothing useful.
37
00:01:44,240 --> 00:01:47,440
The inefficiency is staggering because most polling checks return nothing.
38
00:01:47,440 --> 00:01:51,520
You're paying for compute in bandwidth to ask questions you already know the answer to.
39
00:01:51,520 --> 00:01:55,920
And the worst part is the more responsive you want your system to be, the more often you have to poll.
40
00:01:55,920 --> 00:02:02,080
Want near real-time reactions, you need to check every second, which means 86,400 empty checks per day for nothing.
41
00:02:02,080 --> 00:02:04,520
Now contrast that with an event-driven approach.
42
00:02:04,520 --> 00:02:09,920
Instead of asking anything new over and over, you simply say, "Tell me when something happens.
43
00:02:09,920 --> 00:02:11,320
Don't make me keep asking."
44
00:02:11,320 --> 00:02:16,040
It's like the difference between refreshing your inbox every two seconds and getting a push notification.
45
00:02:16,040 --> 00:02:18,160
One is constant work, the other is waiting to be told.
46
00:02:18,160 --> 00:02:20,600
So if polling is wasteful, what's the better way?
47
00:02:20,600 --> 00:02:22,400
That's where Event Grid comes in.
48
00:02:22,400 --> 00:02:24,400
What is Event Grid, the Smart Home Hub?
49
00:02:24,400 --> 00:02:25,720
Today's topic is Event Grid.
50
00:02:25,720 --> 00:02:26,640
What exactly is it?
51
00:02:26,640 --> 00:02:28,280
Is it just another Azure service?
52
00:02:28,280 --> 00:02:29,960
Or is it something much bigger?
53
00:02:29,960 --> 00:02:31,400
Here's the simplest definition.
54
00:02:31,400 --> 00:02:34,160
Event Grid is a fully managed event-rooting service in Azure.
55
00:02:34,160 --> 00:02:36,280
That's a mouthful, so let me say it in plain English.
56
00:02:36,280 --> 00:02:38,760
Think of Event Grid as the central hub in a Smart Home.
57
00:02:38,760 --> 00:02:43,680
In a Smart Home you have sensors everywhere, motion sensors in the hallway, door sensors on the front door,
58
00:02:43,680 --> 00:02:45,360
temperature sensors in the living room.
59
00:02:45,360 --> 00:02:49,560
Now imagine if each sensor had to talk directly to every device it needed to trigger.
60
00:02:49,560 --> 00:02:53,720
Your motion sensor would need to know about the hallway lights, the alarm system and the thermostat.
61
00:02:53,720 --> 00:02:58,000
The door sensor would need to know about the doorbell, the security camera and the welcome matte light.
62
00:02:58,000 --> 00:02:58,800
That's a mess.
63
00:02:58,800 --> 00:03:01,680
Every time you add a new device, you'd have to rewire everything.
64
00:03:01,680 --> 00:03:04,800
But in a real Smart Home, all those sensors talk to a central hub.
65
00:03:04,800 --> 00:03:07,800
The motion sensor just says "I detected motion."
66
00:03:07,800 --> 00:03:10,120
It doesn't know or care what happens next.
67
00:03:10,120 --> 00:03:11,080
The hub decides.
68
00:03:11,080 --> 00:03:14,120
It turns on the lights, triggers the alarm, and adjusts the thermostat.
69
00:03:14,120 --> 00:03:15,560
The sensor doesn't know who's listening.
70
00:03:15,560 --> 00:03:17,400
The lights don't know who triggered them.
71
00:03:17,400 --> 00:03:18,480
They just trust the hub.
72
00:03:18,480 --> 00:03:21,600
That's exactly what Event Grid does for your Azure services.
73
00:03:21,600 --> 00:03:25,520
When a file is uploaded to blob storage, it doesn't need to know which service should process it.
74
00:03:25,520 --> 00:03:27,560
It just publishes an event to Event Grid.
75
00:03:27,560 --> 00:03:30,400
Then Event Grid routes that event to whatever services are listening.
76
00:03:30,400 --> 00:03:36,000
There's maybe an Azure function that generates a thumbnail, a logic app that sends a notification,
77
00:03:36,000 --> 00:03:39,160
and a storage queue that archives the event.
78
00:03:39,160 --> 00:03:42,840
The publisher doesn't know the subscribers and the subscribers don't know the publisher.
79
00:03:42,840 --> 00:03:45,520
They just trust Event Grid to route the message correctly.
80
00:03:45,520 --> 00:03:49,600
And the pricing model, its paper event, the first 100,000 operations each month are free.
81
00:03:49,600 --> 00:03:53,080
So for most small to medium workloads, it costs essentially nothing.
82
00:03:53,080 --> 00:03:54,680
You're not paying for idle infrastructure.
83
00:03:54,680 --> 00:03:56,960
You're only paying when something actually happens.
84
00:03:56,960 --> 00:03:59,480
Now let's break down the pieces that make this work.
85
00:03:59,480 --> 00:04:03,880
Because Event Grid isn't just one thing, it's a collection of building blocks that work together.
86
00:04:03,880 --> 00:04:05,480
The building blocks events.
87
00:04:05,480 --> 00:04:07,200
Let's start with the most basic piece.
88
00:04:07,200 --> 00:04:08,200
The event itself.
89
00:04:08,200 --> 00:04:10,640
An event is simply a notification that something happened.
90
00:04:10,640 --> 00:04:12,240
That's it. It's not the data itself.
91
00:04:12,240 --> 00:04:15,240
It's a signal that says, "Hey, this thing just occurred."
92
00:04:15,240 --> 00:04:16,520
Think of it like a doorbell.
93
00:04:16,520 --> 00:04:19,120
When someone rings your doorbell, you know someone is at the door.
94
00:04:19,120 --> 00:04:22,160
But the doorbell doesn't tell you who it is, why they're there or what they want.
95
00:04:22,160 --> 00:04:23,880
It just tells you someone is there.
96
00:04:23,880 --> 00:04:25,360
You have to go look for yourself.
97
00:04:25,360 --> 00:04:26,520
Events work the same way.
98
00:04:26,520 --> 00:04:30,760
A blob created event tells you that a file was uploaded to a storage container.
99
00:04:30,760 --> 00:04:32,320
But it doesn't contain the file itself.
100
00:04:32,320 --> 00:04:34,440
It just says, "A file was uploaded."
101
00:04:34,440 --> 00:04:35,440
Here's the name.
102
00:04:35,440 --> 00:04:36,440
Here's when it happened.
103
00:04:36,440 --> 00:04:37,800
Go check it out if you need to.
104
00:04:37,800 --> 00:04:41,360
Now when Event Grid sends an event, it follows a specific format.
105
00:04:41,360 --> 00:04:43,360
You get a few key pieces of information.
106
00:04:43,360 --> 00:04:44,960
The event type tells you what happened.
107
00:04:44,960 --> 00:04:49,040
What could be blob created or blob deleted or resource write success.
108
00:04:49,040 --> 00:04:51,120
The subject tells you what resource it happened to.
109
00:04:51,120 --> 00:04:53,520
That's the exact path to the file or the resource ID.
110
00:04:53,520 --> 00:04:55,280
The event time tells you when it happened.
111
00:04:55,280 --> 00:04:58,160
An ID is a unique identifier for that specific event.
112
00:04:58,160 --> 00:05:02,680
And a small data field contains a few extra details like the file size or the URL to the blob.
113
00:05:02,680 --> 00:05:04,000
Notice I said, "Small data field."
114
00:05:04,000 --> 00:05:05,000
That's important.
115
00:05:05,000 --> 00:05:06,000
Events are lightweight.
116
00:05:06,000 --> 00:05:09,680
They carry just enough information to tell you something happened and where to look.
117
00:05:09,680 --> 00:05:11,200
They don't carry the full payload.
118
00:05:11,200 --> 00:05:13,000
If you need the actual file, you go get it.
119
00:05:13,000 --> 00:05:14,640
The event just points you in the right direction.
120
00:05:14,640 --> 00:05:17,040
This is a key difference between an event and a message.
121
00:05:17,040 --> 00:05:18,560
A message carries a payload.
122
00:05:18,560 --> 00:05:20,000
It's like a letter in an envelope.
123
00:05:20,000 --> 00:05:21,920
The letter contains the actual content.
124
00:05:21,920 --> 00:05:23,400
An event is more like a postcard.
125
00:05:23,400 --> 00:05:24,400
It says, "I'm here.
126
00:05:24,400 --> 00:05:25,880
Come find me."
127
00:05:25,880 --> 00:05:27,360
Events are notifications.
128
00:05:27,360 --> 00:05:28,760
Messages are deliveries.
129
00:05:28,760 --> 00:05:30,080
So events are the signals.
130
00:05:30,080 --> 00:05:31,320
There is something happened.
131
00:05:31,320 --> 00:05:32,320
Announcements.
132
00:05:32,320 --> 00:05:33,400
But where do they actually go?
133
00:05:33,400 --> 00:05:36,040
They don't just float around in the cloud hoping someone picks them up.
134
00:05:36,040 --> 00:05:37,680
They go to a topic.
135
00:05:37,680 --> 00:05:38,680
Topics.
136
00:05:38,680 --> 00:05:39,680
Where events get published.
137
00:05:39,680 --> 00:05:40,680
What exactly is a topic?
138
00:05:40,680 --> 00:05:43,000
Think of it as a mailbox for notifications.
139
00:05:43,000 --> 00:05:46,560
Messages send their events to a topic and the topic holds them until they're routed to the
140
00:05:46,560 --> 00:05:47,560
right place.
141
00:05:47,560 --> 00:05:48,560
Simple as that.
142
00:05:48,560 --> 00:05:51,120
Now, there are two types of topics in Event Grid.
143
00:05:51,120 --> 00:05:52,440
System topics and custom topics.
144
00:05:52,440 --> 00:05:53,640
Let's break them down.
145
00:05:53,640 --> 00:05:55,760
System topics are built in for Azure services.
146
00:05:55,760 --> 00:05:59,880
When you create a storage account, Event Grid automatically creates a system topic for it.
147
00:05:59,880 --> 00:06:01,360
You don't have to do anything.
148
00:06:01,360 --> 00:06:03,040
The events are already available.
149
00:06:03,040 --> 00:06:04,600
You can subscribe to them right away.
150
00:06:04,600 --> 00:06:08,120
Same with Azure Resource Manager, Event Hubs and many other services.
151
00:06:08,120 --> 00:06:09,440
These are the plug and play topics.
152
00:06:09,440 --> 00:06:10,440
They just work.
153
00:06:10,440 --> 00:06:11,680
No setup needed.
154
00:06:11,680 --> 00:06:13,640
Some topics are for your own applications.
155
00:06:13,640 --> 00:06:15,840
Let's say you build a custom ordering system.
156
00:06:15,840 --> 00:06:18,360
You want to publish events when an order is placed.
157
00:06:18,360 --> 00:06:21,960
So you create a custom topic and your application sends events to it.
158
00:06:21,960 --> 00:06:24,640
Then any subscriber can listen for those events and react accordingly.
159
00:06:24,640 --> 00:06:25,640
You control the topic.
160
00:06:25,640 --> 00:06:26,640
You control the events.
161
00:06:26,640 --> 00:06:28,560
Here's a smart home way to think about it.
162
00:06:28,560 --> 00:06:30,200
Topics are like channels on a radio.
163
00:06:30,200 --> 00:06:34,720
You have a motion alerts channel, a temperature changes channel, a door open channel.
164
00:06:34,720 --> 00:06:36,600
Senses published to the appropriate channel.
165
00:06:36,600 --> 00:06:38,120
Subscribers tune into the channels they care about.
166
00:06:38,120 --> 00:06:40,800
The motion sensor doesn't publish to the temperature channel.
167
00:06:40,800 --> 00:06:45,040
It publishes to the motion channel and only subscribers who care about motion listen there.
168
00:06:45,040 --> 00:06:46,040
So events go to topics.
169
00:06:46,040 --> 00:06:47,480
The topic is the mailbox.
170
00:06:47,480 --> 00:06:49,400
But a mailbox is useless if nobody checks it.
171
00:06:49,400 --> 00:06:50,400
So who's listening?
172
00:06:50,400 --> 00:06:51,840
That's the big question.
173
00:06:51,840 --> 00:06:53,600
Subscriptions and handlers who gets the news.
174
00:06:53,600 --> 00:06:54,600
So who's listening?
175
00:06:54,600 --> 00:06:56,280
That's where subscriptions and handlers come in.
176
00:06:56,280 --> 00:06:57,280
Let me explain.
177
00:06:57,280 --> 00:06:58,280
A subscription is a rule.
178
00:06:58,280 --> 00:07:01,520
It says send this topic's events to the specific destination.
179
00:07:01,520 --> 00:07:05,160
You create a subscription on a topic and you tell it where you want the events to go.
180
00:07:05,160 --> 00:07:07,200
That destination is called an event handler.
181
00:07:07,200 --> 00:07:10,560
Event handlers are the services that actually receive and process the events.
182
00:07:10,560 --> 00:07:11,880
They're the ones that do the work.
183
00:07:11,880 --> 00:07:14,360
An event grid supports a wide range of them.
184
00:07:14,360 --> 00:07:16,200
Let's go through the most common ones.
185
00:07:16,200 --> 00:07:18,240
Azure functions are probably the most popular.
186
00:07:18,240 --> 00:07:22,240
You write a small piece of code and when an event arrives, the function runs.
187
00:07:22,240 --> 00:07:23,520
No service to manage.
188
00:07:23,520 --> 00:07:25,120
Logic apps are another common choice.
189
00:07:25,120 --> 00:07:28,200
They let you build visual workflows without writing code.
190
00:07:28,200 --> 00:07:29,440
Great for automation.
191
00:07:29,440 --> 00:07:33,640
Web hooks let you send events to any HTTP endpoint even outside of Azure.
192
00:07:33,640 --> 00:07:36,960
And then you have storage queues and service bus which are useful when you want to buffer
193
00:07:36,960 --> 00:07:39,000
events for later processing.
194
00:07:39,000 --> 00:07:40,520
Now here's where it gets powerful.
195
00:07:40,520 --> 00:07:43,320
An event can trigger multiple handlers in parallel.
196
00:07:43,320 --> 00:07:44,880
This is called the fan out pattern.
197
00:07:44,880 --> 00:07:47,000
Let me explain with the smart home analogy.
198
00:07:47,000 --> 00:07:48,440
Imagine you arrive home.
199
00:07:48,440 --> 00:07:50,000
You walk through the front door.
200
00:07:50,000 --> 00:07:53,240
That single action arriving home could trigger multiple things.
201
00:07:53,240 --> 00:07:54,440
The whole way lights turn on.
202
00:07:54,440 --> 00:07:56,760
The thermostat adjusts to your preferred temperature.
203
00:07:56,760 --> 00:07:58,400
The security alarm disarms.
204
00:07:58,400 --> 00:08:01,000
The coffee machine starts brewing all from one event.
205
00:08:01,000 --> 00:08:03,280
The door sensor doesn't need to know about the coffee machine.
206
00:08:03,280 --> 00:08:05,000
It just says door opened.
207
00:08:05,000 --> 00:08:06,400
The hub handles the rest.
208
00:08:06,400 --> 00:08:07,960
Event grid works the same way.
209
00:08:07,960 --> 00:08:13,000
A single blob created event can trigger an Azure function to generate a thumbnail, a logic
210
00:08:13,000 --> 00:08:17,000
app to send a notification to your team and a storage queue to archive the event for later
211
00:08:17,000 --> 00:08:20,040
auditing all at the same time all from one event.
212
00:08:20,040 --> 00:08:21,600
The publisher doesn't know about any of them.
213
00:08:21,600 --> 00:08:24,120
It just published the event and event grid handled the routing.
214
00:08:24,120 --> 00:08:25,120
That's the magic of it.
215
00:08:25,120 --> 00:08:26,120
But here's a question.
216
00:08:26,120 --> 00:08:28,960
What if you don't want every handler to get every event?
217
00:08:28,960 --> 00:08:31,680
What if you only want certain events to reach certain handlers?
218
00:08:31,680 --> 00:08:33,120
That's where filtering comes in.
219
00:08:33,120 --> 00:08:35,520
But we'll cover that in another episode.
220
00:08:35,520 --> 00:08:37,920
Filtering only the events you care about.
221
00:08:37,920 --> 00:08:39,520
So what happens without filtering?
222
00:08:39,520 --> 00:08:42,600
Every subscription receives every single event published to that topic.
223
00:08:42,600 --> 00:08:44,080
It gets noisy and wasteful fast.
224
00:08:44,080 --> 00:08:47,400
Imagine your motion sensor triggers every time your cat walks by.
225
00:08:47,400 --> 00:08:50,640
You'd get a notification every few minutes and pretty soon you'd just ignore them.
226
00:08:50,640 --> 00:08:52,400
That's the problem with unfiltered events.
227
00:08:52,400 --> 00:08:55,120
Event grid gives you a way to filter those events.
228
00:08:55,120 --> 00:08:58,560
So each subscription only gets the ones it actually cares about.
229
00:08:58,560 --> 00:09:02,160
You can filter on the event type, the subject path, or even specific data fields inside the
230
00:09:02,160 --> 00:09:03,160
event.
231
00:09:03,160 --> 00:09:04,160
The idea is simple.
232
00:09:04,160 --> 00:09:05,400
Only deliver what matters.
233
00:09:05,400 --> 00:09:06,400
Here's a real example.
234
00:09:06,400 --> 00:09:09,120
Say you have a storage account with multiple containers.
235
00:09:09,120 --> 00:09:12,540
One holds invoices, another holds photos, and another holds logs.
236
00:09:12,540 --> 00:09:16,020
You want to trigger a process only when a new invoice shows up, not when a photo or log
237
00:09:16,020 --> 00:09:17,020
file appears.
238
00:09:17,020 --> 00:09:19,200
So you set up a filter on the subject field.
239
00:09:19,200 --> 00:09:21,400
The subject contains the full path to the blob.
240
00:09:21,400 --> 00:09:25,680
You tell event grid to only match subjects that start with, push, blob services, default
241
00:09:25,680 --> 00:09:27,280
or containers invoices.
242
00:09:27,280 --> 00:09:30,960
Now only files uploaded to that invoices container trigger your handler.
243
00:09:30,960 --> 00:09:32,680
Photos and logs are ignored completely.
244
00:09:32,680 --> 00:09:35,000
You can also use prefix and suffix filtering.
245
00:09:35,000 --> 00:09:40,640
Maybe you only want to trigger on files ending with post PDF or files that start with urgent.
246
00:09:40,640 --> 00:09:44,000
Event grid gives you that control without any extra code.
247
00:09:44,000 --> 00:09:45,720
Let's go back to the smart home analogy.
248
00:09:45,720 --> 00:09:47,720
You don't want your bedroom lights to turn on.
249
00:09:47,720 --> 00:09:49,840
Every time motion is detected anywhere in the house.
250
00:09:49,840 --> 00:09:53,760
You only want them on when motion happens in the bedroom and maybe only after sunset.
251
00:09:53,760 --> 00:09:54,760
That's filtering.
252
00:09:54,760 --> 00:09:58,160
It's about making sure the right events reach the right handlers and nothing else.
253
00:09:58,160 --> 00:10:00,600
So events are filtered and sent to the right handlers.
254
00:10:00,600 --> 00:10:01,600
That sounds great.
255
00:10:01,600 --> 00:10:03,200
But what happens when something goes wrong?
256
00:10:03,200 --> 00:10:04,280
What if the handler is down?
257
00:10:04,280 --> 00:10:06,040
What if the network fails?
258
00:10:06,040 --> 00:10:09,120
Reliability, retries and dead lettering.
259
00:10:09,120 --> 00:10:11,320
So events are filtered and sent to the right handlers.
260
00:10:11,320 --> 00:10:12,320
That sounds great.
261
00:10:12,320 --> 00:10:13,880
But what happens when something goes wrong?
262
00:10:13,880 --> 00:10:15,040
What if the handler is down?
263
00:10:15,040 --> 00:10:16,280
What if the network fails?
264
00:10:16,280 --> 00:10:18,200
Event grid handles this with retries.
265
00:10:18,200 --> 00:10:22,160
If a handler doesn't respond, event grid doesn't just give up and lose the event.
266
00:10:22,160 --> 00:10:24,920
It tries again using something called exponential back off.
267
00:10:24,920 --> 00:10:27,760
But first retry happens quickly maybe a few seconds later.
268
00:10:27,760 --> 00:10:30,760
If that fails, the next retry waits a bit longer.
269
00:10:30,760 --> 00:10:31,760
Then longer.
270
00:10:31,760 --> 00:10:34,680
Event grid keeps retrying for up to 24 hours.
271
00:10:34,680 --> 00:10:37,800
That's a lot of chances for the handler to come back online.
272
00:10:37,800 --> 00:10:38,800
But here's the thing.
273
00:10:38,800 --> 00:10:41,280
What if the handler is permanently broken?
274
00:10:41,280 --> 00:10:43,880
What if someone deleted the Azure function by accident?
275
00:10:43,880 --> 00:10:47,560
What if the endpoint URL changed and nobody updated the subscription?
276
00:10:47,560 --> 00:10:50,600
After 24 hours of retries, event grid still can't deliver.
277
00:10:50,600 --> 00:10:51,840
So where does that event go?
278
00:10:51,840 --> 00:10:53,240
That's where dead lettering comes in.
279
00:10:53,240 --> 00:10:54,760
Dead lettering is your safety net.
280
00:10:54,760 --> 00:10:59,440
You configure a storage location, usually a storage queue or a blob storage container.
281
00:10:59,440 --> 00:11:03,440
If all retries fail, event grid moves the event to that dead letter location.
282
00:11:03,440 --> 00:11:04,520
It's not lost.
283
00:11:04,520 --> 00:11:07,000
It's sitting there waiting for you to investigate.
284
00:11:07,000 --> 00:11:08,240
Why does that matter?
285
00:11:08,240 --> 00:11:11,960
Because in a real system, you don't want events to disappear silently.
286
00:11:11,960 --> 00:11:16,000
Imagine a payment processing pipeline, a customer places an order, an event fires.
287
00:11:16,000 --> 00:11:18,400
The handler that processes the payment is down.
288
00:11:18,400 --> 00:11:21,040
Without retries and dead lettering, that order is just gone.
289
00:11:21,040 --> 00:11:24,600
The customer thinks they ordered something, the system has no record of it, and you never
290
00:11:24,600 --> 00:11:25,720
know it happened.
291
00:11:25,720 --> 00:11:27,560
With retries, the system keeps trying.
292
00:11:27,560 --> 00:11:30,920
With dead lettering, if it still fails, you have a record of the failure.
293
00:11:30,920 --> 00:11:33,920
You can investigate, fix the issue, and reprocess the event.
294
00:11:33,920 --> 00:11:35,720
Let's go back to the smart home analogy.
295
00:11:35,720 --> 00:11:39,760
Imagine you arrive home and the hub sends a signal to turn on the hallway light, but the
296
00:11:39,760 --> 00:11:41,120
light bulb is broken.
297
00:11:41,120 --> 00:11:42,720
The hub doesn't just give up.
298
00:11:42,720 --> 00:11:44,440
It tries again a few seconds later.
299
00:11:44,440 --> 00:11:45,440
Nothing.
300
00:11:45,440 --> 00:11:46,440
It tries again.
301
00:11:46,440 --> 00:11:47,440
Still nothing.
302
00:11:47,440 --> 00:11:49,120
After a few attempts, it logs the failure.
303
00:11:49,120 --> 00:11:51,640
You get a notification that the hallway light needs attention.
304
00:11:51,640 --> 00:11:52,840
The event isn't lost.
305
00:11:52,840 --> 00:11:53,840
It's recorded.
306
00:11:53,840 --> 00:11:55,760
You know something went wrong and you can fix it.
307
00:11:55,760 --> 00:11:56,960
That's what event grid does.
308
00:11:56,960 --> 00:11:58,320
It doesn't just fire and forget.
309
00:11:58,320 --> 00:11:59,320
It keeps trying.
310
00:11:59,320 --> 00:12:01,560
And if it can't deliver, it tells you.
311
00:12:01,560 --> 00:12:02,840
Event grid sounds great.
312
00:12:02,840 --> 00:12:04,800
But when should you use something else?
313
00:12:04,800 --> 00:12:08,120
Because not every messaging problem is an event grid problem.
314
00:12:08,120 --> 00:12:10,560
Event grid versus event hubs versus service bus.
315
00:12:10,560 --> 00:12:14,520
Azure has three main messaging services and people mix them up all the time.
316
00:12:14,520 --> 00:12:16,280
Event grid event hubs and service bus.
317
00:12:16,280 --> 00:12:19,920
They all move data around, but they solve completely different problems.
318
00:12:19,920 --> 00:12:20,920
Let's break it down.
319
00:12:20,920 --> 00:12:23,560
Event grid is for discrete events and notifications.
320
00:12:23,560 --> 00:12:25,040
Think of it as a notification bell.
321
00:12:25,040 --> 00:12:29,120
When something happens, a file gets uploaded, a VM spins up or an order is placed.
322
00:12:29,120 --> 00:12:32,440
Event grid rings that bell and tells the right handler to react immediately.
323
00:12:32,440 --> 00:12:35,640
It's built for serverless triggers, automation and fan out patterns.
324
00:12:35,640 --> 00:12:38,640
If you need to react to something, this is your tool.
325
00:12:38,640 --> 00:12:40,760
Event hubs is for high throughput streaming.
326
00:12:40,760 --> 00:12:44,760
Imagine millions of IoT devices sending data every second, or application logs, or click
327
00:12:44,760 --> 00:12:46,800
stream data from a website.
328
00:12:46,800 --> 00:12:51,400
Event hubs ingests that massive stream and makes it available for analytics pipelines.
329
00:12:51,400 --> 00:12:53,680
It's not about reacting to individual events.
330
00:12:53,680 --> 00:12:56,520
It's about collecting and processing data over time.
331
00:12:56,520 --> 00:12:59,560
Think of it as a massive pipeline, not a notification bell.
332
00:12:59,560 --> 00:13:01,120
Service bus is for reliable messaging.
333
00:13:01,120 --> 00:13:02,160
This is your mail room.
334
00:13:02,160 --> 00:13:04,440
It handles queues and topics where order matters.
335
00:13:04,440 --> 00:13:06,040
Payment processing, order fulfillment.
336
00:13:06,040 --> 00:13:09,560
Any scenario where you need guaranteed delivery first and first out ordering or transactional
337
00:13:09,560 --> 00:13:10,560
messaging.
338
00:13:10,560 --> 00:13:13,560
Service bus ensures nothing is lost in everything stays in sequence.
339
00:13:13,560 --> 00:13:15,680
It's what you use when you can't afford a mistake.
340
00:13:15,680 --> 00:13:17,200
Here's a simple rule to remember.
341
00:13:17,200 --> 00:13:18,360
Event grid reacts.
342
00:13:18,360 --> 00:13:19,960
Event hubs streams.
343
00:13:19,960 --> 00:13:21,360
Service bus coordinates.
344
00:13:21,360 --> 00:13:24,920
If you need to trigger a function when a blob is uploaded, use event grid.
345
00:13:24,920 --> 00:13:29,000
If you need to ingest millions of sensor readings per second, use event hubs.
346
00:13:29,000 --> 00:13:33,320
If you need to process orders and sequence with guaranteed delivery, use service bus.
347
00:13:33,320 --> 00:13:35,240
And here's the thing, you can use them together.
348
00:13:35,240 --> 00:13:39,000
Event grid can root events to event hubs for long term storage and analytics.
349
00:13:39,000 --> 00:13:41,360
Event hubs feeds data into stream analytics.
350
00:13:41,360 --> 00:13:43,360
Service bus queues work for downstream processing.
351
00:13:43,360 --> 00:13:45,040
They're not competitors.
352
00:13:45,040 --> 00:13:47,760
They're complimentary tools in your architecture toolbox.
353
00:13:47,760 --> 00:13:49,240
So where does that leave us?
354
00:13:49,240 --> 00:13:50,240
Let's wrap this up.
355
00:13:50,240 --> 00:13:53,560
Event grid is the smart notification hub for your Azure services.
356
00:13:53,560 --> 00:13:57,440
It replaces wasteful polling with instant event driven reactions.
357
00:13:57,440 --> 00:14:00,720
Instead of constantly asking anything new, you wait to be told.
358
00:14:00,720 --> 00:14:04,240
And when something happens, event grid roots that notification to the right handlers with
359
00:14:04,240 --> 00:14:06,760
filtering, retries and dead lettering built in.
360
00:14:06,760 --> 00:14:08,400
The key takeaway is simple.
361
00:14:08,400 --> 00:14:10,080
Move from polling to event driven.
362
00:14:10,080 --> 00:14:12,840
Stop wasting compute and bandwidth on empty checks.
363
00:14:12,840 --> 00:14:16,800
Start building reactive systems that only do work when there's actual work to do.
364
00:14:16,800 --> 00:14:17,800
Here's your challenge.
365
00:14:17,800 --> 00:14:20,160
Think of one manual check in your environment.
366
00:14:20,160 --> 00:14:24,240
In script that pulls a folder, one service that queries a database every few seconds.
367
00:14:24,240 --> 00:14:27,480
Ask yourself, could this be an event instead?
368
00:14:27,480 --> 00:14:29,640
If the answer is yes, you know where to start.
369
00:14:29,640 --> 00:14:32,240
That's it for this episode of Microsoft Knowledge Nuggets.
370
00:14:32,240 --> 00:14:35,880
If you found this helpful, subscribe on your favorite podcast platform and share this with
371
00:14:35,880 --> 00:14:37,880
someone starting there as your journey.
372
00:14:37,880 --> 00:14:40,080
I'm Mirko Peters and I'll see you in the next episode.
