CH11-01: Event-Driven Architecture Mental Model

Goal

Chapter 5 separated commands, events, streams, and workflows. This chapter takes the event idea further and turns it into an architecture pattern.

Event-driven architecture is a way to let systems react when something meaningful happens. A file is uploaded. An order is created. A payment changes status. A resource is modified. The event is the signal that the change occurred, and other systems can respond without the original producer calling each one directly.

The durable idea for this section is:

Event-driven architecture works when events have clear meaning, contracts, consumers, reliability expectations, and owners.

The Short Version

The easy way to describe event-driven architecture is:

One system publishes an event, and other systems react.

That is true, but it is not enough for architecture work. A stronger description is:

One system publishes a well-defined fact, a routing layer delivers it to interested consumers, handlers process it safely, durable messaging protects important work when needed, and operations teams can see failures.

The first version sounds like a trigger. The second version sounds like a system you can operate.

Events Are Facts, Not Vague Instructions

An event says that something already happened.

Examples:

DocumentUploaded
OrderCreated
PaymentCompleted
InventoryAdjusted
CustomerProfileChanged

These names describe facts. They do not tell one specific receiver what to do. That difference matters because the producer should not need to know every downstream reaction.

A command has a different meaning. A command asks a receiver to do work, such as ReserveInventory or GenerateInvoice. Commands usually need a clear receiver and durable processing. Events usually announce a fact so independent subscribers can react.

Streams are different again. A stream is a continuous sequence of records over time, often used for telemetry, analytics, or high-volume ingestion. Workflows coordinate steps, decisions, and state across a business process. Event-driven architecture may use queues, streams, or workflows, but an event itself starts from the simpler idea that something meaningful happened.

The Event Flow

A practical event-driven design has more than a producer and a consumer. It has a flow of responsibilities:

Event source
  -> Event router
  -> Event handler
  -> Optional durable queue
  -> Observability and failure handling

Responsibility	Architecture Question
Event source	What system knows that the meaningful change happened?
Event contract	What event name, schema, version, and identifiers describe the fact?
Event router	How does the event reach the right subscribers without direct coupling?
Event handler	What code reacts, validates, calls dependencies, and records outcomes?
Durable work	Which reactions must be stored and processed reliably even during failure?
Observability	How will teams trace, retry, dead-letter, alert, and investigate the flow?

Azure commonly uses Event Grid for event routing, Azure Functions or Azure Container Apps for handlers, and Azure Service Bus when a reaction becomes reliable work that must not be lost. Those service names will appear throughout the chapter. For now, focus on the job each one performs.

How Event-Driven Design Changes Coupling

In a request-response design, one component often calls another directly:

Upload service -> Metadata service -> Search index service -> Notification service

This can be simple, visible, and appropriate. But as the number of reactions grows, the original service can become responsible for too many downstream details.

An event-driven design changes the relationship:

Upload service publishes DocumentUploaded
    |
    v
Event router
    |-- Metadata extractor reacts
    |-- Search indexer reacts
    |-- Notification handler reacts
    |-- Audit recorder reacts

The upload service owns the upload and the event contract. It does not need to know every consumer. New consumers can be added without changing the upload service.

This is useful, but it is not magic. Coupling moves from direct calls into event contracts, payload design, retry behavior, schema compatibility, monitoring, and ownership. A weak event contract can create just as much trouble as a weak API contract.

Example: Uploaded Document Processing

Imagine a document platform. A user uploads a contract PDF. The upload service stores the file and publishes a ContractDocumentUploaded event.

Several things may happen next:

Reaction	Possible Design
Extract metadata from the document.	A Function handles a small processing task.
Generate previews or thumbnails.	A containerized worker handles heavier processing.
Update search.	A subscriber indexes the document by ID.
Notify a reviewer.	A handler calls a notification service or starts a workflow.
Process compliance checks.	A Service Bus queue protects durable work that must complete.

The event is not "please do all of these steps." The event is "this document was uploaded." Each subscriber owns its own reaction and failure behavior.

Common Mistakes

Using events as vague remote procedure calls, such as ProcessEverythingNow, instead of naming a fact that happened.
Publishing large payloads that expose internal data structures and make every subscriber depend on producer internals.
Assuming event-driven design automatically removes coupling when the schema, versioning, and ownership are unclear.
Designing only the happy path and forgetting retries, duplicate delivery, dead-letter handling, and alerts.
Treating every asynchronous interaction as an event, even when the communication is really a command, stream, or workflow.

If Someone Asks You

What is event-driven architecture?

A good answer is:

Event-driven architecture is a design style where systems publish facts about meaningful changes and other systems react independently. A good design does more than connect triggers. It defines event contracts, routing, handlers, durable work where needed, retry behavior, failure paths, observability, and ownership.

What You Should Remember

Events decouple producers and consumers only when meaning, contracts, and operations are clear.

Questions to Check Your Understanding

How is an event different from a command?
What responsibilities appear around event routing?
Why is observability important in event-driven systems?