# One order. Four teams need to know.

> Why the fourth subscriber is the only argument for Event Grid that matters.

- **Format:** short video, 10 steps, ~32 seconds
- **Topic:** Azure Event Grid — why one "OrderPlaced" event with subscriptions beats a checkout service that calls email, inventory and shipping itself.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Tags:** azure, azureeventgrid, eventgrid, eventdrivenarchitecture, servicebus, eventhubs, systemdesign, microsoftazure, azurecloud, cloudarchitecture, microservices, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-event-grid-order-placed/

---
## What you'll learn

- Why checkout should not call email, stock and shipping itself
- How subscriptions and filters fan one event out to four teams
- What Event Grid retries before a delivery is dead-lettered

## Understand it one step at a time

### 1. Order placed. Now what?

Three things must happen next: send the email, reserve the stock, create the shipping label.

### 2. Checkout is calling all three

Sequential HTTP calls inside the request. The customer waits for work they never asked about.

### 3. Add a fourth, redeploy checkout

Loyalty points want the same event. Now you edit and ship the one service nobody wants to touch.

### 4. Fix: Azure Event Grid

Checkout publishes one event and returns. It does not know who is listening, and does not care.

### 5. One event, many subscriptions

The subscription is the fan-out unit. Event Grid pushes to each handler — nobody polls anything.

### 6. Filters decide who gets what

Event type, subject prefix, or a field inside the payload. A subscriber never sees what it filtered out.

### 7. It retries, then dead-letters

A failing handler gets exponential backoff for up to 24 hours — and only its own subscription is affected.

### 8. New subscriber, zero changes

Loyalty creates its own subscription. Nobody edited checkout, nobody redeployed, nobody was consulted.

### 9. Which one? Grid, Hubs, Bus

Commands to be done, facts to react to, and streams to be read. Three jobs, three services.

### 10. Publish the fact. Let them subscribe.

The publisher should never hold a list of who cares. That list is the coupling.

---

## The takeaway

**The publisher should not know who is listening**

If adding a consumer means editing the producer, you built a phone tree, not an event.
