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.

This puts the real world at odds with classic software development in which everything is regimented and proscribed by specific rules. The traffic light, for example, changes at programmed intervals without fail unless it becomes damaged. Classic monolithic design with all decisions determined and executed without regard to anything else happening outside the system.

The cars and their 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 or coupled to the other in anything other than a loosely enforced common understanding of the rules.

The Top 5 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 to them. 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 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” connected to the IoT it would be impossible to anticipate all possible events and tightly couple them to all others. Having systems able to detect and react to events that take place in time enables the interoperability absolutely necessary to the functioning of the 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 Anticipation of the Unknown

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

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. While the developer may react to this reality by attempting to program the production of as many events as possible to achieve greater granularity, the reality is that this may easily become counter-productive as it adds greater complexity which only reduces the ability to trace the logic, test, and 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 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, now much of what the system must process 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 so they and others may evaluate and modify the code in the future if need be.

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 classic waterfall, 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, just 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. Error Handling Hampered

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 the first state’s law enforcement vehicles and the second. This is an ideal place for the getaway car to getaway.

5. 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 it circumscribes each process it is preferable to design but obtaining that 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.


We certainly hope you’ll include Tiempo Development in your search for a capable partner to work with on your EDA project. Knowledge transfer and earning our reputation for excellence are our highest priorities. Contact us today to learn how we can help.


Event-Driven Architecture eBook CTA