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.