Explain By Example: Event Grid

Disclaimer: This content is not officially endorsed by Microsoft.

I'm trying out a new series titled, 'Explain By Example'.

One thing I have noticed about myself is that whenever I learn something new, I like to use analogies to help make it "click" or "stick" in my head and so I thought, hey, maybe someone else might also benefit from these weird, quirky, fun stories and examples that I make up to help me learn and so I've decided to share some of them with you!

// Comments and feedback are highly appreciated.

The first topic is: What is Event Grid?

Well, the actual documentation says its the event-routing service on Azure. Typically, if you are building event-driven applications, your application might emit events that needs to be received by some other application or vice versa. Event Grid allows you to specify your application as the event source and some other application as the event handler and automatically route events emitted from your application to the specified event handler.

For the non-technical folks, what does this mean?

Imagine you want to catch up with a friend over coffee. How do you initialize this? You might send them a text message or message them over a social media platform or you can do it the old-fashion way and send them an email. Sending this message means you have emitted an event saying, "Let's catch up over coffee!" and the action for this event is to get a coffee. Usually, there would be more communication back and forth to arrange a date, time, and place. Your friend might respond with, "Sounds great, let's meet at Coffee Grid next Tuesday at 9am". Let's say this message got accidentally sent to someone else with the same name as you. They could have a guess at what the context of message meant but they might not know the location of Coffee Grid or even be in the same timezone. In a way, applications communicate with each other in a similar way through emitting events and messages. An application would emit an event saying, "This thing happened". Event Grid routes that event to some other application who knows exactly what "Coffee Grid and Tuesday 9am" means. That other application will then perform some action. And you can rest assure knowing that event won't get accidentally delivered to some other application with the same name.

So, what does any of this have to do with this weird (and highly designer) diagram I drew below:

Well, when I first looked at Event Grid, I thought, "Wow, that is a lot of terminology to wrap my head around" so I came up with a story to help distinguish between Publisher, Topics, Events, Subscribers, etc.

So I started a company, a very prominent company that has no name. This no name company has a board of executives and a pool of workers that act as assistants to the executives. Rather than having a one-to-one Executive-to-Assistant relationship, the company has a strange policy where the executives have shared access to the Assistant Pool resource. Each executive have their own tasks list in which they must write all their tasks to. The company then handles assigning those tasks to an assistant. The executives trusts that all their tasks will be handled effectively by the assistant. The company purchases a software called 'Event Grid' to handle all the task assigning.

The company in this case represents anything that publishes to Event Grid. In Event Grid terminology, they are known as the 'Publisher'. The company comes up with the CEO task list, the CIO task list, the CFO task list, etc. These are known as 'Topics' in Event Grid. So the CEO sends their tasks to the CEO task list, the CIO sends tasks to the CIO task list, etc. The tasks in this case represents 'Events' and so naturally the sender of those events are known as the 'Event Source'.

From the Assistant Pool, let's say John gets assigned to handle all the tasks in the CEO tasks list. So as soon as a task lands in the CEO task list, John gets notified he has to do something. In Event Grid terms, John is a subscriber and he has subscribed to the CEO Topic. That's known as an 'Event Subscription'.

Now, John may not always handle the CEO's tasks. His contract with the CEO tasks list might expire by the end of the year and this is called an 'Event Subscription Expiration'. John may also subscribe to handle the CIO's tasks and the CFO's tasks at the same time. Like I mentioned before, it doesn't have to be a one-to-one relationship.

Let's say John, Sally, and Meg all subscribe to the CEO tasks lists but John might only handle the CEO's laundry tasks, Sally only handles the CEO's coffee requests, and Meg only knows how to schedule meetings on behalf of the CEO. If the task comes in as a phone call, it gets directed to John. If the task comes in as an SMS text message, it gets directed to Sally. If the task comes in as an email, it gets directed to Meg. This is known as 'Filtering' in Event Grid. The phone call, SMS message, and email are known as 'Event Types' so you can use Event Grid to filter events to event handlers based on event types.

When John gets notified of the 'Laundry for CEO' event, he will forward that request to a Laundromat. In this case, John is the 'Event Handler' for the 'Laundry for CEO' event. When John makes a request to the Laundromat, he becomes the event source and emits a 'Dry clean these 5 shirts' event to the Laundromat. So now, the Laundromat is the event handler for the 'Dry clean these 5 shirts' event.

When John sends the 'Dry clean these 5 shirts' event to the Laundromat, the Laundromat might be closed. What Event Grid will do in this case is redeliver the event until Laundromat receives it (when it opens up for business again).

So there you go, if you ever need to explain Event Grid to someone, start by explaining how the CEO of a no name company can always get a clean shirt first!

Get started with Event Grid now!

P.S: If you want to support Explain by Example, you can buy me a coffee here ?