.NET 8 + Azure Event-Driven Architecture — Notes From the Field

Event-driven architecture on Azure looks simple in the diagram and gets interesting the moment real constraints arrive — security, latency tolerance, data residency, and the question of what happens when a message can't be processed. Here are the decisions that carry the most weight.

Isolated worker, not in-process

On .NET 8, Azure Functions runs in isolated worker mode by default, and the older in-process model is on the way out. The practical win is control — your own dependency-injection container, your own middleware, startup that feels like a normal ASP.NET Core app. If you're starting fresh, start isolated.

Premium plan when the network is private

Consumption plans are cheap and scale to zero, but the moment you need VNet integration — and any serious enterprise integration platform does — you're on a Premium plan with pre-warmed instances. That's a cost decision to surface early, not a surprise in month three.

Service Bus for work, Event Grid for facts

A useful mental model: Service Bus carries work that must be done (process this record, with retries and a dead-letter queue when it can't); Event Grid broadcasts facts that have happened (this opportunity was matched — react if you care). Conflating the two is where event-driven systems get tangled.

Design for the message that fails

The tutorials show the happy path. Production is defined by the unhappy one. Dead-letter queues, idempotency, and a clear story for poison messages aren't optional extras — they're the difference between a platform you trust and one that quietly drops data. Decide the failure behaviour before you write the success path.

Zero-trust by default

Private networking, managed identity over connection strings, and least-privilege everywhere. It's more setup up front, but retrofitting security onto an integration platform that's already live is one of the more expensive mistakes a team can make.