Event-Driven Architecture

What This Chapter Is About

Help readers design Azure event-driven architecture by separating event notification, event processing, durable work, contracts, retries, dead-letter handling, observability, and ownership.

This chapter builds from the integration-service mental model in Chapter 5 and show how Event Grid, Functions, Container Apps, Service Bus, and related services can combine in a complete pattern.

Keep one durable idea in view:

Event-driven architecture reacts to meaningful changes through explicit event contracts, routing, processing, reliability, and operations.

Sections

1. Event-Driven Architecture Mental Model

2. Event Sources, Routing, and Event Grid

3. Processing with Functions and Container Apps

4. Reliable Processing with Service Bus and Dead-Letter Handling

5. Event Contracts, Observability, and Operations

6. Event-Driven Architecture Scenario

How the Chapter Develops

The chapter develops in this order:

1. Start with events as signals that something meaningful happened.

2. Explain event sources, routing, filtering, and Event Grid's role.

3. Explain event processing with Functions or Container Apps.

4. Add Service Bus when processing must be durable, ordered, retried, or dead-lettered.

5. Explain event contracts, schema ownership, observability, idempotency, and operations.

6. Apply the model to a workflow triggered by uploads or business events.

Together, these sections show that event-driven architecture is about reliability and contracts, not just reacting to triggers.

What You Will Be Able to Do

By the end of this chapter, the reader should be able to:

• Distinguish event notification from durable work processing.

• Explain where Event Grid fits in event routing.

• Choose between Functions and Container Apps for event processing at a high level.

• Explain when Service Bus should be added for reliability.

• Discuss event contracts, retries, idempotency, dead-letter handling, and observability.

• Sketch an event-driven Azure pattern with clear ownership.

Key Ideas

• Events say that something happened; they should not be vague remote procedure calls.

• Event Grid is useful for routing notifications to subscribers.

• Processing logic still needs identity, retries, state handling, monitoring, and failure design.

• Service Bus helps when work must be durably processed rather than merely announced.

• Event schemas and versioning need owners.

• Event-driven systems must be observable because the flow is distributed.

Related Provider-Neutral Reading

• Event-Driven Architecture explains event meaning, durable work, contracts, failure handling, and operations before applying a provider lens.