Event-Driven Provider Lens Notes

Goal

The provider-neutral chapter explains event-driven architecture as a pattern of meaningful facts, routing, handlers, durable work, contracts, observability, and ownership. This provider lens translates those responsibilities into Azure examples.

Future AWS or GCP lenses should be added only after official provider documentation is checked.

The durable idea is:

Provider event services should implement event responsibilities, not blur commands, events, streams, and workflows.

The Short Version

The weak provider question is:

Which Azure event service should we use?

The better provider question is:

Are we routing a fact, processing a reaction, protecting durable work, streaming records, or coordinating a workflow?

Azure services can participate in more than one architecture, so start with communication meaning before choosing service names.

Azure Responsibility Map

Pattern Responsibility	Azure Implementation Lens	Design Note
Route event notifications	Azure Event Grid	Useful for publish-subscribe event distribution, event subscriptions, filtering, push or pull delivery, and event-driven integration.
Small event-triggered handlers	Azure Functions	Useful for focused event-driven code with triggers, bindings, multiple languages, hosting options, and monitoring integration.
Containerized or heavier event processors	Azure Container Apps	Useful for containerized workers, event-driven processing, jobs, revisions, KEDA-supported scaling, internal ingress, and logs.
Durable work processing	Azure Service Bus	Useful for queues, topics, subscriptions, dead-letter queues, duplicate detection, sessions, and reliable work handoff.
Observability	Azure Monitor and Application Insights	Useful for metrics, logs, traces, dashboards, alerts, and troubleshooting distributed flow.
Workload access	Managed identities and Key Vault	Useful for secure access to resources and secrets without unmanaged credentials.

This table is not a recipe. A design may use Event Grid for notification, Functions for small handlers, Service Bus for durable work, Container Apps for heavier workers, and Azure Monitor for telemetry. The service mix should follow event meaning and reliability needs.

Example: Commerce Order Events on Azure

One possible Azure implementation looks like this:

Orders service records order
	-> publishes OrderPlaced event
	-> Azure Event Grid routes notification
			|-- Azure Function sends lightweight customer confirmation
			|-- Fraud signal handler records analysis input
			|-- Analytics projection handler updates read model
			|-- Fulfillment starter places durable work on Service Bus

Azure Service Bus queue: StartFulfillment
	-> Container Apps worker processes fulfillment work
	-> repeated failures move to dead-letter queue

Azure Monitor and Application Insights collect metrics, logs, traces, alerts, and dashboards.

The important design choice is not that Event Grid, Functions, Service Bus, and Container Apps all appear. The important choice is that each service has a distinct responsibility.

Keep Routing and Durable Processing Distinct

Azure Event Grid is a strong lens for routing event notifications. It can distribute events from Azure services, custom applications, and partner systems to subscribers. It supports HTTP push and pull delivery models, filtering, and event handler integration.

Azure Service Bus is a strong lens for durable business work. It stores messages in queues or subscriptions until receivers process them, supports publish-subscribe topics, and provides features such as dead-letter queues, sessions, duplicate detection, and transactions within its model.

Do not use one service name as a shortcut for communication meaning. A fact announcement, a durable command, and a high-volume stream are different contracts even when all of them are asynchronous.

Handler Runtime Notes

Azure Functions can fit small event-triggered units of work. Official documentation describes event-driven triggers and bindings, scenarios such as processing file uploads and queues, monitoring through Azure Monitor and Application Insights, and several hosting options.

Azure Container Apps can fit containerized workers or heavier event processors. Official documentation describes event-driven processing, jobs, revisions, KEDA-supported scaling, internal service discovery, secrets, virtual network integration, and log monitoring.

Choose by processing shape, not only by trigger. A small validation handler may fit Functions. A video processing worker, document analysis worker, or dependency-rich background process may fit containers.

Common Mistakes

Treating event routing and durable messaging as interchangeable.
Calling commands events because both are asynchronous.
Publishing provider claims without official documentation.
Ignoring handler ownership because event routing looks managed.
Forgetting idempotency because a managed service retries delivery.
Monitoring only the platform service and not business-flow outcomes.

If Someone Asks You

How should provider services appear in an event-driven article?

A good answer is:

Provider services should appear as implementation lenses for event responsibilities. In Azure, Event Grid can route event notifications, Functions can run small event handlers, Container Apps can run containerized workers, Service Bus can protect durable work, and Azure Monitor/Application Insights can help observe the flow. The provider services do not replace the architecture questions: what fact happened, who owns the contract, who reacts, what work must complete, and how failures are handled.

What You Should Remember

Provider event services are lenses for event meaning, routing, durability, and operations.

Questions to Check Understanding

Which event responsibilities should a provider lens translate?
Why should routing and durable processing stay distinct?
Which provider facts need official source verification before publication?