Introduction to Event-Driven Architecture

Introduction to Event-Driven Architecture

As new technologies like 5G and edge computing steadily move us toward the Fourth Industrial Revolution, characterized by automation, robotics, and machine learning, the need for real-time data processing is becoming increasingly important. From businesses that rely on Big Data to glean customer insights to IoT applications that leverage machine-learning and AI, we are generating a torrent of data—much of which must be instantly analyzed and acted upon to ensure its relevance.

To accommodate the scale and sophistication of this process-intensive, time-sensitive, and data-hungry environment, a new kind of application architecture is needed—a model that can provide real-time processing with scalability, resilience, and efficient resource use. Event-driven architecture, or EDA, provides these benefits by replacing the traditional request-response paradigm with one that automatically produces, detects, and reacts to events. This blog post will provide an introductory overview of EDA, including its key definitions and characteristics, how it works, and its use cases and benefits.

What Is EDA?

A 2020 article from DZone defines EDA as “a software development method for building applications that asynchronously communicate or integrate with other applications and systems via events.” While this definition provides clarity for those familiar with programming, this sentence may need some unpacking for the uninitiated.

What Are Events?

In EDA, an event is any occurrence that results in a change in state in the application. Events can originate from a user interacting with a system (a voice command or mouse click), an external source (a sensor detecting changes in light or temperature), or within a system (loading a program). Examples of events include:

  • home security: motion is detected outside;
  • intelligent traffic light: a driver runs a red light;
  • e-commerce: a user cancels an order; or
  • shipping: an item arrives at its destination.

Although some events may not warrant any action, others may set in motion one or more predetermined actions. For example:

  • the camera begins recording and lights turn on;
  • a photo of the vehicle is taken and transmitted;
  • a refund issued, an email is sent, and inventory is updated; or
  • the sender receives a notification and the order is closed.

Synchronous vs. Asynchronous Communication

In synchronous communication, processes must take place in a specific order, and all other activities are blocked until a response is received or the process times out. The synchronous process is analogous to a queue in a checkout stand at your local grocer, where each customer must be serviced in sequence with equal priority. No one customer (i.e. process) can be expedited to the front of the queue if they possess special attributes.

This is not a problem for monolithic legacy applications consisting of tightly coupled processes that are dependent on each other. However, modern applications are loosely coupled, consisting of many independent processes called microservices that communicate via API calls. This makes synchronous programming problematic because, as Stack Overflow explains, “if a service has resources blocked (e.g: a thread is hanging), timeouts are now exponential.” As a result, latency increases with an application’s complexity, confounding the application’s capacity for real-time processing.

In contrast, asynchronous communication does not need to occur in a specific order, allowing processes to take place simultaneously and independently of each other. Rather than a response-request model, communication flows in one direction, eliminating the need to wait for a response before executing code and—as a result—reducing latency and eliminating the risk of timeouts. In terms of our grocery line example, the asynchronous model is akin to a cashier expediting the checkout process and reducing the queue length by prioritizing customers who have cash or credit cards at ready, while placing check-writing customers in another queue to complete their task of writing the remittance details and authorizing the check.

How Does EDA Work?

Components of EDA

EDA architecture is composed of event producers, event channels, and event consumers. A 2020 InfoQ article distinguishes between the three components:

  • Event producers push data to channels whenever an event takes place.
  • Channels push the data received from event producers to event consumers.
  • Event consumers subscribe to channels and consume the data.

In other words, event producers are responsible for detecting events and sending relevant data to event channels. Event channels determine where to send notifications that an event has occurred. These messages are received by one or more event consumers, which may take action in response to events or simply note that it has occured.

Characteristics of EDA

Using event channels as middlemen allows event producers to be decoupled from event consumers. As a result, they can act independently of each other, enabling more scalability and fault tolerance. In addition, organizing applications around events enables code to run both asynchronously and automatically without user interaction.

In other words, EDA is push-based where data is broadcasted to participants, devices and applications, rather than pull-based, meaning that data consumers act on data as it is received, rather than when it is requested. For example, the early days of email used a pull-based system, where users had to connect to the Internet and click a button in order to check for email. Now, notifications are pushed to users, alerting them each time a new email is received, removing the need to periodically check for new mail.

The characteristics of EDA include:

  • push-based communication;
  • decoupled components;
  • scalable and available by design;
  • asynchronous unidirectional workflow; and
  • centered around events, rather than mutable databases.

Examples of EDA Systems

One example of EDA is a fraud detection system. As online banking and e-commerce continue to grow in popularity, cyber criminals have more opportunities to engage in fraud over the Internet, using strategies that are harder to detect than in-person transactions. In such situations, immediate action is critical to mitigate financial damage and catch cybercriminals. With EDA, fraudulent patterns of behavior can be analyzed, detected, and dealt with in real-time.

For example, an EDA-based fraud detection system might train algorithms using historical behavioral patterns. When event producers recognize these patterns, they can send notifications through event channels, which might trigger actions such as stopping payments and alerting stakeholders such as card holders, their credit card companies, and the e-commerce. In the event of a false positive, such as irregular activity during a valid e-commerce transaction, the cardholder can then verify the transaction as legitimate, setting events in motion that will validate the purchase, notify relevant parties, and improve the fraud detection algorithm with the new information gleaned.

In addition to fraud detection, EDA is frequently used in:

  • healthcare monitoring;
  • real-time marketing;
  • payment processing;
  • financial trading;
  • cyber security; and
  • a wide variety of IoT use cases.

Benefits of EDA

EDA’s numerous benefits make it a crucial tool for solving the problems of the modern Internet. Not only is fault tolerance increasingly important as more and more mission-critical services move into the cloud, the explosion of data generated by IoTs, digital businesses, and other online services demand efficient resource use to mitigate the cost and environmental impact of processing this data. An estimated 59 ZB of data was generated in 2020, according to IDG, which predicts that “The amount of data created over the next three years will be more than the data created over the past 30 years, and the world will create more than three times the data over the next five years than it did in the previous five.”

In this environment, applications will not only need to scale up to meet spikes in demand, but rapidly scale back down to reduce the resource waste that would occur from consistently operating at a massive scale. Fortunately, EDA is scalable by nature, capable of fine-grained elasticity by scaling up and down at the level of individual events. In addition, retrieving data in real time is less expensive and resource-intensive than periodically polling remote services for state changes, reducing network and CPU utilization and resulting in fewer SSL/TLS handshakes.

Another issue caused by modern application development is that the use of multiple services creates issues with database access. As noted in a 2020 Stack Overflow blog post, “when multiple services share a database, you may create problems like dependencies between teams on schema changes or performance issues.” And when developers attempt to solve this problem by using a separate database per service, they have to “deal with distributed transactions and the complexity of maintaining multiple databases.” However, with EDA, event logs can provide a centralized data store that acts as a single source of truth for distributed applications, which is useful in central auditing and policy enforcement.

The advantages of EDA include:

  • Highly scalable
  • Fault tolerant
  • Cost and resource efficient
  • Central auditing in distributed systems


A 2017 Gartner press release noted the necessity of moving to an event-centric business strategy, noting that “A digital business technology foundation must support continuous availability, massive scalability, automatic recovery and dynamic extensibility.” Due to these benefits, Gartner touted EDA as a crucial tool for supporting digital business transformation. Nearly four years later, EDA is more relevant than ever. Not only does it provide real-time processing for IoTs and low-latency websites, it delivers on-demand scalability, fault tolerance for mission-critical services, a single source of truth for distributed applications, and efficient analysis, monitoring, and logging of data to lower costs and resource utilization.

Azion’s Edge Functions helps companies seamlessly transition to an event-driven architecture by creating event-driven functions each designed to perform a specific task, reducing the need to rewrite or rebuild large codebases. Using our edge computing platform, Edge Functions automatically execute on the edge location closest to end users for the lowest possible latency, cost, and resource use. In addition, real-time insights about application performance can be easily accessed through Real-Time Metrics, which integrates with popular Big Data and SIEM tools to analyze and respond to events in real time. To learn more about Edge Functions, visit our product page or sign up for a free account to start building event-driven functions today.