Event-Driven

Event-driven is the half of the API world that the request-response paradigm spent two decades overshadowing, and it represents one of the most important shifts in how I think about what an API actually is. For most of the API era, when people said “API” they meant a synchronous, request-response, HTTP REST interface: a client asks, the server answers, the conversation ends. Event-driven flips that. Instead of the consumer constantly asking “has anything changed? has anything changed?”, the producer pushes information the moment something happens. The consumer subscribes and reacts. This inversion — from pull to push, from polling to subscribing, from request-response to publish-subscribe — is not a minor technical variation. It’s a fundamentally different model of how systems communicate, and I’ve come to see event-driven architecture as a sign of maturity in an organization’s API journey rather than an exotic alternative to “real” APIs.

The event-driven instinct was present in the API world early, even before the vocabulary caught up. I was writing about PubSubHubbub for APIs in 2011 — the publish-subscribe protocol that let feeds push updates instead of making everyone poll — and about Superfeedr’s use of XMPP over HTML5 WebSockets the same year, for real-time feed delivery. These were early recognitions that the polling model was wasteful and that pushing data when it changed was the better pattern for a whole class of use cases. Webhooks were the most accessible expression of this: the “reverse API,” where instead of you calling the provider, the provider calls you when an event occurs. Webhooks became ubiquitous because they were simple — just an HTTP POST to a URL you registered — and they were most people’s first taste of event-driven thinking. The Adyen webhook implementation I praised in 2025 as a good use of OpenAPI’s webhook support shows how far that simple idea matured: webhooks became a first-class, specifiable part of the API contract rather than an afterthought bolted onto a REST API.

The protocol landscape of event-driven APIs is genuinely diverse, and understanding it means letting go of the idea that an API is one thing. Webhooks are the simplest. Server-Sent Events (SSE), which I wrote about in 2017 as part of the API landscape, provide a one-way stream from server to client over a long-lived HTTP connection — perfect for things like live updates and long-running operations. WebSockets provide full-duplex, bidirectional real-time communication. And then there’s the heavier message-broker infrastructure: Kafka, AMQP, MQTT, and the pub/sub systems that power event streaming at scale. I dug into the thinking behind Kafka’s protocols in 2018 because Kafka represents a different center of gravity entirely — durable, replayable event logs that treat the stream of events as the source of truth rather than the current state. Each of these protocols fits different needs: webhooks for simple notifications, SSE for one-way streams, WebSockets for interactive real-time, Kafka and message queues for high-throughput durable event streaming. The diverse API toolbox I kept advocating for is precisely the recognition that you need all of these, matched to the use case, rather than forcing everything through REST.

Streaming and real-time were where I personally went deepest into event-driven, through my work with Streamdata.io. Streamdata.io was a service that turned polling REST APIs into real-time streams — caching and pushing data so consumers got updates the instant they happened instead of hammering the API with repeated requests. I wrote extensively about this from 2015 onward: API streaming, caching and pushing data, reducing the polling of existing APIs, the differential responses that made it efficient by sending only what changed. The transit data work was the perfect illustration — real-time bus and train data, GTFS-realtime feeds, the value of pushing live transit information to riders instead of making apps poll constantly. Breaking down the value of real-time APIs in 2018, I kept coming back to the same point: for a huge class of data — financial, transit, social, operational — the value is highest at the moment of change, and an architecture that delivers it at that moment beats one that makes consumers discover the change by asking repeatedly. Real-time isn’t a luxury for these use cases; it’s the whole point.

AsyncAPI was the development that gave event-driven APIs the thing they had always lacked: a specification. I wrote in 2017 about AsyncAPI as a specification format for message-driven APIs, and it mattered enormously because event-driven APIs had been the wild west — no standard way to describe a topic, a channel, a message schema, a binding. AsyncAPI brought to event-driven what OpenAPI brought to REST: a machine-readable contract you could design, document, validate, and build tooling around. I got involved in moving the specification forward, in defining its protocol bindings, in mapping the relationship between OpenAPI paths and AsyncAPI topics, and in the broader work of aligning OpenAPI, AsyncAPI, and GraphQL as complementary specifications rather than competitors. AsyncAPI is the reason event-driven APIs could be governed, discovered, and managed with the same discipline as REST APIs. Without a specification, event-driven was destined to remain ad hoc and ungovernable. With one, it became a first-class citizen of the API lifecycle.

The infrastructure and schema layer matured alongside the specification, and the event broker became central. Amazon EventBridge, which I wrote about in 2019, was significant because it brought event routing and a schema registry into the cloud mainstream — a managed event bus with discovery and schema management built in. The Confluent Schema Registry did the same for the Kafka world. These schema registries matter because in an event-driven system, the message schema is the contract — when you’re pushing events to consumers you’ve never met, the structure of those events has to be reliable and discoverable, and schema registries are how you govern that. This is the event-driven parallel to everything API management did for REST: you need to know your event schemas, validate them, version them, and manage their evolution, because a breaking change to an event schema breaks every downstream consumer reacting to it, often silently.

The governance and management gap is the honest challenge of event-driven, and it’s the work I’ve been pointing at most recently. I wrote in 2025 about backfilling everything API management did for HTTP APIs but for event-driven — because the truth is that the management, observability, security, and governance tooling for event-driven APIs lags far behind what we built for REST over two decades. We have decades of mature tooling for managing request-response APIs — gateways, keys, rate limits, analytics, documentation portals. The event-driven equivalent is younger and less complete. Managing an event-driven API landscape, as I wrote about in 2019, requires rethinking what API management even means when there’s no request to intercept, no synchronous call to authenticate, no response to cache. The event-driven view of the API lifecycle, which I sketched in 2021, is the project of mapping every stage we know from REST — design, deploy, secure, document, discover, govern, deprecate — onto the asynchronous, streaming, message-driven world. That mapping is still being worked out, and it’s some of the most important infrastructure work left to do in the API space.

The framing I keep returning to is that event-driven is not a replacement for REST but a complement, and the mature organization uses both deliberately. I’ve written for years that the API is not just REST — that REST, hypermedia, GraphQL, gRPC, and event-driven are all tools in a diverse toolbox, each suited to different needs. In 2025 I added Model Context Protocol to that list, because the agentic era is adding yet another communication pattern. The right architecture is hybrid: synchronous request-response where you need a direct answer, event-driven where you need to react to change as it happens, and the various protocols matched to the specific characteristics of each use case. Streaming and event-driven architecture represents maturity in your API journey, as I argued in 2018, precisely because adopting it means you’ve moved past the assumption that every integration is a synchronous request and started designing for the reality that much of what matters in a system is events — things happening — that consumers need to know about and react to in real time. The organizations that have internalized this build systems that are more responsive, more decoupled, and more aligned with how the real world actually works, which is not in tidy request-response pairs but in a continuous, asynchronous stream of events.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Event-Driven

References

Guidance Details

Explore more

Discover APIs