When to Use Event-Driven Architecture (EDA)

Event Driven Architecture Table of Contents:


 

Ask experts what is needed for the success of the Internet of Things (IoT) now and in the future and one of the responses you will often hear is “interoperability.” This makes sense. The devices themselves never know what they will be asked to interoperate with, who made it, what its protocols are. Like the introduction of printer drivers in the distant past, something is needed to enable any device to connect to any other device.

The past few years have seen rapid changes in many aspects of how we use technologies. Classic monolithic applications have given way to orchestrated microservices in containers that are readily transported throughout the “cloud.” In addition to interoperability we need greater interactivity. The traditional method of having a user issue a request or command has been replaced by the more interactive concept of identifying an event, a change in state sufficient to warrant response or responses from other parts of the system, or of other systems.

A common example of EDA begins when a motorist runs a red light. A camera mounted near the traffic light is triggered by an event, the movement of the automobile beyond the stop line. It then records the event. That recording, along with the time and location data, triggers the registering of a violation and the creation of a summons.

Automated mailing systems mail out those summonses and the motorist receives theirs a few days later. The violation is eventually resolved when payment is issued, another event, but the record of the violation remains for consolidation with previous and future violations to drive the decision to suspend that driver’s license temporarily. Note that the payment began with the violator writing and mailing a check or using an online credit card service that is received by the system that issued the summons. This example integrates interactions between different systems as well as human involvement.

As to when to use Event-Driven Architecture: EDA is ideal when you want to capture behaviors in the real world as well as the digital, along with pertinent facts that can be used for decision-making. Record of the event is stored for future analysis. This reflects how humans react to events happening around them.

From Requests to Events

According to Cisco Systems, the number of devices connected to the global internet exceeded the number of people using it in 2008 and has continued to increase at an accelerating pace ever since. Where the original interactions conducted across the internet were from people to machine and back to person, the presence of tens of thousands more devices produced interactions between machines.

The change from request-driven architecture to event-driven parallels the increase in machine-to-machine (M2M) activity as opposed to the decreased percentage of internet transactions that are person-to-machine. When machines talk to machines, their interactions trigger events, advertising something has happened. Some events communicate a result or trigger further events. Because of that, there is a need for speed of response. To compare request-driven and event-driven let us examine two interactions:

  • A pedestrian comes to a corner where the light is red forbidding them to cross. They press a button on a nearby lamppost that says, “Press Here to Cross.” That pedestrian will wait for a considerable time for that light to change. This request-driven event anticipates some latency.
  • An autonomous vehicle approaches the same corner intending to turn left. As it gets close, the light turns red and cars coming the opposite way begin to proceed. If that event, the light turning red, experiences any latency whatsoever it may become a matter of life-and-death for several people. This requires event-driven response that is consistently high-speed with no latency.

Characteristics of EDA Applications

EDA facilitates high volume and high velocity of data such as traffic between things on the internet. More complex events may require identification of multiple events in diverse locations at different points in time, perhaps even on different systems, or multiple subsystems may need to process responses to the same event. EDA serves these scenarios bringing true real-time processing with minimum or no latency whatsoever in a completely decentralized platform that can even include systems from different organizations, critical in an interoperable IoT.

Deciding When to Use an Event-Driven Architecture

The decision to use EDA should consider the presence or absence of several characteristics:

Asynchronous and Loosely Coupled

Each component of an EDA application operates independently which allows them to move on to their next task even while downstream components are performing further processing. In fact, each service in the EDA have no knowledge or awareness of other components including protocols and other details. This also allows an event router to queue events received where they can wait to be processed when their intended event consumer becomes available. They can also be tested, validated, updated and deployed independently.

Since the event queue in the event router stores every event, events may be “replayed” later for purposes of analysis and recovery of lost data.

Scaling

Absent any awareness of each other, the loose coupling of the various components of a service makes scaling simple. Each service may be scaled independently without dependencies on any other components.

EDA significantly increases process velocity and agility, making it ideal for modern applications that use microservices, or any application featuring decoupled components. This requires shifting your paradigm to align more closely with EDA. Things to consider include:

  • Resilience of event sources. Especially if the expectation is that you will service every event your event source must guarantee delivery.
  • How you will troubleshoot anomalies. Since there is no designed workflow in an EDA system, it is not possible to trace errors through the code. You will want to create a strategy that monitors and evaluates each segment independently.
  • Data management. Where earlier systems collected data and then processed and analyzed it before producing an outcome, with EDA the event itself is the data. If you ever need to rebuild the current state during any past event transaction, you will need to provide indexing and deduplication.

When decision time is measure in milliseconds instead of minutes, for example determining whether a financial exchange is fraudulent while the transaction is in mid-flight, your best choice is EDA. Other examples include payment processing, website monitoring, online customer experiences, and other real-time marketing activities.

Improving AI Experiences Requires Event Driven Architecture

As the use of natural-language AI-driven human interfaces increases, EDA will be critical to the natural cadence of conversation required. If a user asks a question and the AI is delayed in replying, the illusion of true interactivity may be shattered. Latency is once again the enemy.

Event-Driven Architectures will also be pivotal in enabling the AI to consume events that may be relevant to its human user. An early example is the traffic function of some GPS devices. When heavy traffic or an accident is detected ahead the AI is cued to advise the user and provide them with alternate routes.

EDA puts the digital side of the human/digital interface on more of an even footing, a level playing field with the digital intelligence. When both can detect an event and decide to take specific actions in response the concept of a truly symbiotic relationship between people and processors comes much closer to becoming a reality.

 


Event Driven Architecture Table of Contents: