What is Event-Driven architecture?

Home > Glossary > Event-Driven architecture

Event-driven architecture (EDA) is a software design pattern in which the flow of a system is driven by events — signals that something happened, like an order being placed or stock running low. Instead of components calling each other directly and waiting for a reply, they emit events and react to them. Producers publish events without knowing who will handle them; consumers listen for the events they care about. This decoupling of producers from consumers is the pattern’s defining trait.

An EDA system has three parts: producers that emit events, consumers that react to them, and an event broker (such as Kafka, RabbitMQ, or AWS EventBridge) that routes events between them. Communication is asynchronous — a producer doesn’t wait for downstream processing to finish — so each component can scale and run on its own schedule. That’s why EDA powers many real-time, high-throughput platforms.

The main benefits are loose coupling, scalability, and real-time responsiveness: services can be added or changed without rewiring the whole system, and a load spike in one area doesn’t cascade into others. The trade-offs are added complexity — asynchronous, distributed flows are harder to trace and debug, and teams must handle eventual consistency, duplicate or out-of-order events, and failure recovery. This is where patterns like idempotency, retries with backoff, and monitored error queues become essential.

In ecommerce, EDA fits naturally: an order placed on the storefront emits an event that independently triggers inventory reservation, ERP sync, payment capture, and customer notification — all in near real time, instead of one long synchronous transaction. That keeps pricing, stock, and order status consistent across the storefront and back-office systems without the store waiting on every step.