The same ordinance-published event must update analytics logging and invalidate a live agent cache. What Event Grid pattern should the city use?
Select an answer to reveal the explanation.
Short Explanation
Fan-out is one city memo, two inboxes—analytics and the live agent cache each get their own Event Grid subscription without making one wait on the other.
Full Explanation
One ordinance-published domain event often must drive multiple independent municipal side effects: analytics logging and live agent cache invalidation are classic examples. Event Grid’s fan-out pattern—one event, multiple subscriptions/handlers—lets each concern scale and fail on its own. Analytics can write metrics while a second handler busts Redis or another cache the agent uses for ordinance answers, without the publisher knowing each consumer.
Chaining the analytics Function to call cache invalidation only after a long synchronous wait couples unrelated concerns: analytics latency or outage blocks cache freshness, and you invent a brittle internal HTTP chain instead of declarative subscriptions. Publishing the event to exactly one handler and manually emailing the other team fails automation and audit. Storing the event once in a local file on a single VM with no subscribers is not an event mesh: no retry, no independent consumers, and a single point of failure for citywide ordinance updates.
Exam caveat: fan-out still needs per-subscription filters, retry, and dead-letter; identical handlers racing without idempotency can double-apply side effects. Prefer event types that mean “published” rather than intermediate edit noise. Operational check: publish one ordinance-published event and verify both analytics and cache-invalidation handlers receive it; kill one handler and confirm the other still succeeds via its own subscription retries.