A software architecture pattern promoting the production, detection, consumption of, and reaction to events. Systems are designed to respond to state changes asynchronously through event messages.
Event-driven Architecture
Event-driven Architecture (EDA) is a software architecture pattern built around the production, detection, consumption of, and reaction to events. Instead of components calling each other directly and waiting for a response, systems emit events when something changes and other systems react asynchronously, decoupling producers from consumers in both time and dependency.
- Events as the unit of communication - A state change — an order placed, a payment cleared — is published as an event rather than triggering a direct call.
- Producers and consumers, loosely coupled - Publishers don’t know or care who consumes their events, letting each side scale and evolve independently.
- Channels and brokers - Message brokers, queues, and streams carry events between systems, providing buffering, routing, and durability.
- Asynchronous, reactive flow - Consumers respond when events arrive rather than on a synchronous request/response clock, which suits real-time and high-throughput workloads.
Across the API landscape, event-driven architecture is where APIs move beyond the request/response model into streaming, webhooks, and message-driven integration — a shift I’ve long treated as a sign of maturity in an API journey. It is the architectural home of AsyncAPI, which does for event-driven APIs what OpenAPI did for HTTP ones, and it underpins the Enterprise Integration Patterns that route and transform those events. As agents begin reacting to real-time state rather than polling for it, EDA becomes central to how machine-to-machine systems stay current.
Standards that realize this practice
A practice is an argument about how to work; a standard is a way of actually doing it. These are the standards this practice is carried out with — the place where the idea becomes an artifact someone can implement against.
AsyncAPI
Describes the channels, messages and participants an event-driven system is assembled from.
CloudEvents
A common envelope for events, so a consumer can read one without knowing which producer emitted it.
MQTT
A transport the pattern is frequently built on, particularly where the publishers are devices.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.