Event-driven architecture
Event-driven architecture is a software design pattern in which services communicate by producing and reacting to events, rather than calling each other directly, enabling loosely coupled, asynchronous systems.
Overview
In an event-driven architecture (EDA), a service that has something happen — an order placed, a user signing up, a file uploaded — publishes that fact as an event, without knowing or caring which other services will react to it. Other services subscribe to relevant event types and react independently. This is in contrast to a request-driven model, where one service directly calls another's API and waits for a response.
Core components
- Producers: services or systems that emit events when something of interest occurs.
- Event broker / bus: middleware (e.g., Apache Kafka, RabbitMQ, AWS EventBridge, Google Pub/Sub) that receives, stores, and routes events from producers to consumers.
- Consumers: services that subscribe to event types and execute logic in response, such as sending a confirmation email, updating inventory, or triggering a downstream data pipeline.
Events are typically immutable facts about something that already happened (e.g., "OrderPlaced"), described in past tense, distinguishing them from commands ("PlaceOrder") which instruct a system to do something.
Why teams adopt it
- Loose coupling: producers and consumers don't need to know about each other, so services can be added, removed, or changed independently.
- Scalability: producers aren't blocked waiting on consumers; multiple consumers can process the same event stream in parallel.
- Resilience: if a consumer is temporarily down, durable brokers retain events until it recovers, rather than losing the interaction entirely.
Tradeoffs
EDA introduces eventual consistency — a consumer may act on an event slightly after it happened, so different parts of the system can temporarily see different states. Debugging is also harder: tracing a business process across many independently-reacting services requires good observability (correlation IDs, distributed tracing) since there's no single call stack to follow.
Relationship to data pipelines
Event-driven patterns underpin change data capture and streaming ingestion: a database change becomes an event that downstream consumers (including data pipelines that eventually land data in a warehouse or lakehouse queried by tools like DuckDB) can react to, rather than data engineers having to poll source systems on a schedule.
Related terms
Apache Kafka is an open-source distributed event streaming platform built around a durable, partitioned log for publish-subscribe messaging at scale.
Stream processing →Stream processing is the continuous computation of data as individual events arrive, rather than waiting to collect them into a batch. It powers use cases that need results within seconds or milliseconds of an event occurring.
Webhook →A webhook is a way for one system to notify another in real time by sending an HTTP POST request to a pre-configured URL whenever a specific event happens, rather than the receiving system having to poll for updates.
Amazon S3 →Amazon S3 (Simple Storage Service) is a highly scalable, durable, and secure object storage service provided by Amazon Web Services (AWS).
Debezium →Debezium is an open-source distributed platform for change data capture (CDC), which streams row-level insert, update, and delete events out of databases in real time.
Schema registry →A schema registry is a centralized service that stores, versions, and validates data schemas — typically for Avro, Protobuf, or JSON Schema — used to keep producers and consumers in streaming systems like Kafka compatible as schemas change.
FAQS
A message queue is one implementation mechanism — infrastructure for passing messages between services. Event-driven architecture is the broader design pattern of building systems around producing and reacting to events; it can be implemented using message queues, event logs like Kafka, or pub/sub services.
No, though they're often used together. Microservices is an architectural style of building an application as independently deployable services. Event-driven architecture is a communication pattern those services can use to interact asynchronously, instead of calling each other's APIs directly.
