Disadvantages of Event-Driven Architecture

The real world is a messy state of affairs. Things happen for all kinds of reasons, sometimes for no apparent reason at all. Other things and people react even though they may bear no direct connection with the thing that happened.

For example, when a traffic light turns red, it really doesn’t know whether drivers seeing it will stop their cars. And in a very real sense, it doesn’t care. Even if failure to stop causes a major accident, the traffic light will just keep on doing its job—unless one of the vehicles impacts the control box.

Scenarios such as this put the real world at odds with classic software development, in which everything is regimented and proscribed by specific rules. The traffic light changes at programmed intervals without fail, unless it is damaged. This is a classic example of monolithic design—with all decisions determined and executed without regard to anything else happening outside the system.

Cars and drivers, however, are event-driven. They will continue proceeding until they encounter something from the traffic control system, which is only connected to them by inference. If a light turns red, they’re supposed to stop, but there is no programming that enforces or requires that to happen. One event is not connected to the other by anything other than a loosely-enforced, common understanding of the rules.

To solve for this challenge, it’s necessary to align software development with the real world, and that’s where an Event-Driven Architecture (EDA) can help. This series has detailed the benefits of EDA, but while applying this approach, it’s also important to understand the disadvantages, as described below. By being aware of these EDA attributes, you can adjust your software coding plans accordingly.

Top 4 Disadvantages of Event-Driven Architectures

1. The Double Edge of Loosely-Coupled Events

One of the more obvious ways in which the real world intersects with programming can be found in the Internet of Things (IoT). Various sensors recognize actions taken by humans and set off responses. The sensors are tightly-coupled to the systems that perform the responses but can only be considered loosely-coupled to the person setting them off.

Extending this, the response taken by one system may trigger events in other systems. Each system is very loosely-coupled to the others and cannot anticipate any particular event happening at any particular time. By employing an event-driven architecture (EDA), we enable all systems to react in specific ways to events triggered by other systems.

Given the vast number of “things” that are connected to the IoT, it would be impossible to anticipate all possible events and tightly couple them to all others. Implementing systems that are able to detect and react to events taking place in real time enables the interoperability that’s absolutely necessary to a functioning IoT.

At the same time, EDA operates within a void of connectivity. Since a system that produces an event is not directly coupled to systems that react to it, space is created between them, which becomes a point of vulnerability that could be exploited by those of bad intent. Loose coupling is required to achieve scale but must be evaluated carefully to protect or prevent security gaps.

2. Documenting the Anticipation of the Unknown

Developers live in a world that they themselves proscribe. Much time and effort go into anticipating and making allowances for all the various possible outcomes from each step in their programs.

This is the antithesis of EDA, in which there can be little or no anticipating which systems will produce what events at any given time. A developer may react to this reality by attempting to program the production of as many events as possible to achieve greater granularity. But the reality is…this may easily become counter-productive. It adds greater complexity that only reduces the ability to trace the logic, test the code, and then troubleshoot—while also potentially overwhelming event consumers with an overabundance of events to process.

Due to the inherent complexity of creating software that evaluates events rather than objects and which must allow for unrecognized events, malformed events, or other anomalies, the EDA learning curve can be extensive. This is exacerbated by how opposed EDA thinking is to classic software development architectures. Replacing a world in which every possibility was contained within the system, known, and provided for, much of what the system must process now occurs outside the system. As such it cannot be documented.

Within software designed with EDA, developers must take care to avoid generic names and flags for events their software produces. This enables them and others to evaluate and modify the code in the future.

3. Anticipating the Unforeseen

Testing is difficult in an EDA environment, which is designed to anticipate the unknown but also may trigger unforeseen and undesirable responses. In the classic waterfall approach, programming testing includes seeking potential loops—with the potential to become endless.

Endless loops are every bit as possible between disparate systems that react to each others’ events as they are within monolithic code. But they are far more difficult to test for where there are far too many potential permutations of action.

Since events are asynchronous, there can be no anticipation of a specific order of occurrence or assured delivery of anything. Duplicates may occur in differing conditions that may each require a contextual response.

4. Hampered Error-Handling

Perhaps the most confounding challenge in using EDA is the difficulty in providing root-cause analysis of any given failure. As event producers and event consumers proliferate, it becomes more and more difficult to trace back activities occurring within and between them.

Like an interstate automobile pursuit, the most difficult transition occurs when the getaway vehicle reaches and crosses over the border—where the chase must then transition between each state’s law enforcement vehicles. This is an ideal place for that getaway car to get away!

Event-Driven Architecture Is Not a Panacea

It is very important that EDA developers not come to view EDA as a solution for every problem—a cure-all. Given that EDA circumscribes each process, it is a preferable way to design applications, but obtaining value may not be worth the complexity introduced by all the interprocess interaction.

EDA enables the interactivity and interoperability that the growing IoT runs on, but that doesn’t make it the right answer for everything. It is critical to evaluate the interactivity and interoperability required by any given use-case to determine if EDA is really called for. It may require too much troubleshooting and maintenance to be used in situations that simply don’t need it.

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”]