This topic describes the concept, benefits, diagram, and scenarios of an event-driven architecture (EDA).

What is an EDA?

An EDA uses events to trigger services and communicate between applications. The EDA is commonly used to build microservice applications. An event is a change in status, or an update, like an item being placed in a shopping cart on an e-commerce website. An event can carry status or be an identifier.

The EDA has three key components: event producer, event router, and event consumer. Event producers publish events to event routers, and event routers filter the events and push events to event consumers. Event producers and event consumers are decoupled. This allows them to be independently scaled, updated, and deployed.


An EDA has the following benefits:

  • Independent scaling

    By reducing the coupling between event producers and event consumers, they need only to focus on event routers. This means that each service independently runs. If one service fails, other services normally run. Event routers act as an elastic buffer that can accommodate surges in workloads.

  • Agile development

    Developers no longer need to write custom code to poll, filter, and route events. Event routers automatically filter and push events to event consumers. Event routers also reduce the coupling between event producers and event consumers and accelerate the development.

  • Ease of audit

    An event router acts as a centralized location to audit applications and define policies. These policies can restrict who can publish and subscribe to the event router and control which users and resources have access to your data. You can also encrypt events in transit and at rest.

  • Cost effectiveness

    EDAs are push-based. Therefore, when events are pushed from event producers to event routers, the events are pushed to event consumers on demand. This way, you do not need to pay for continuous polling to check for an event. This means less network bandwidth consumption, less CPU utilization, less idle fleet capacity, and fewer Secure Sockets Layer (SSL) or Transport Layer Security (TLS) handshakes when events are delivered.


The following figure shows a sample EDA for an e-commerce site. This architecture enables the site to respond to changes from various sources during times of peak demand without causing applications to unexpectedly quit or over-provisioning resources.



EDAs can be used in the following scenarios:

  • Cross-account and cross-region data replication

    You can use an EDA to coordinate systems that run in and are deployed across different regions and accounts. You can develop, scale, and deploy services independently of other teams by using an event router to transfer data between systems.

  • Resource status monitoring and alerting

    Instead of continuously checking on your resources, you can use an EDA to monitor and receive alerts on anomalies, changes, and updates. These resources include buckets, database tables, serverless functions, and compute nodes.

  • Fanout and parallel processing

    Assume that you have a large number of systems that need to respond to events. You can use an EDA to fan out the events without the need to write custom code to push the events to each event consumer. The event router pushes the events to the systems, each of which can process the events in parallel with a different purpose.

  • Integration of heterogeneous systems

    If you have systems running on different stacks, you can use an EDA to share information between these stacks without coupling. The event router establishes indirection and interoperability among the systems so that they can exchange messages and data while they remain agnostic.