Event-Driven Architecture
What This Chapter Is About
Help readers design a provider-neutral event-driven pattern by treating events as meaningful facts with explicit sources, routing, handlers, durable processing, contracts, retries, idempotency, observability, and ownership.
This chapter builds on the microservices chapter. Once capabilities are separated, events help systems react to meaningful changes without turning every collaboration into a synchronous call.
Keep one durable idea in view:
Event-driven architecture reacts to meaningful changes through explicit event contracts, routing, processing, reliability, and operations.
Sections
How the Chapter Develops
The chapter develops in this order:
Start with events as facts that something meaningful happened.
Explain event sources, routing, filtering, and subscription boundaries.
Explain event processing and handler ownership.
Add durable work, retries, dead-letter handling, and idempotency.
Explain event contracts, schema ownership, observability, replay, and operations.
End with provider lens notes that translate the pattern into Azure and future AWS examples after the event model is clear.
What You Will Be Able to Do
By the end of this chapter, the reader should be able to:
Distinguish events from commands and requests.
Explain source ownership, routing, subscriptions, and handlers.
Choose when event notification is enough and when durable processing is needed.
Discuss retries, dead letters, idempotency, event contracts, and replay.
Sketch an event-driven pattern with clear observability and ownership.
Add provider lenses without reducing the pattern to one event service.
Key Ideas
Events say something happened; they should not be vague remote procedure calls.
Routing and processing are separate responsibilities.
Handlers own side effects and must be idempotent.
Durable work needs retries, dead-letter handling, and recovery paths.
Event schemas and versioning need owners.
Event-driven systems need correlation and operational visibility.