When to Use An Event-Driven Architecture (EDA)

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. IoT devices never know what devices they will be asked to interoperate with, who the manufacturer is, and what the 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 a user issuing a request or command has been replaced by the more interactive concept of identifying an event—a change in state sufficient to warrant a response or responses from other parts of the system or other systems.

EDA In Action
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 send out the summons, and the motorist receives it 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 you should use an 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. A record of the event is stored for future analysis. This reflects how humans react to events happening around them.

Evolving 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 machines and then back to the people, the presence of tens of thousands more devices produced interactions among machines.

The change from Request-Driven Architecture to the event-driven approach parallels this 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 speedier responses. To compare the request-driven and event-driven approaches, 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 an event-driven response that is consistently high-speed with no latency.

Characteristics of EDA Applications

EDA facilitates high data volumes and high velocity 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. These systems may need to process responses to the same event.

EDA serves these scenarios by bringing true real-time data processing with minimum or no latency whatsoever. The completely decentralized platform can even include systems from different organizations, which is 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 perform further processing. In fact, each service in the EDA has no knowledge or awareness of other components, including protocols and other details.

This also allows an event router to queue received events where they can wait for processing until 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 when aligning with EDA:

• The resilience of event sources—Especially if the expectation is that you will service every event. If so, your event source must guarantee delivery.
• Anomaly troubleshooting—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 measured in milliseconds instead of minutes, such as determining whether a financial exchange is fraudulent while the transaction is in mid-flight, your best choice is EDA. Other examples include payment processing, web product 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 the required conversation. 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.

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

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

Event-Driven Architecture is just one of the methods our product development teams use to drive your success. Contact 3Pillar Global today to learn how we can do it for you.

[adinserter name=”EDA Guide”]