Overcoming Challenges of Event-Driven Architectures

Event-Driven Architecture (EDA) solves many of the difficulties encountered when building and operating classic monolithic applications in which a failure of any service will bring the entire application down. Instead of responding to commands or requests. Services designed using EDA are very loosely coupled to other services. Each awaits the occurrence of specific events to trigger them to take specific actions. Failure of any service will be quickly resolved by immediate re-instantiation of that service. The entire application is never threatened since it is fundamentally an assembly of many individual services.

In earlier posts in this series, we discussed the many advantages of EDA and reviewed the challenges that often face those attempting to convert existing monolithic applications into microservice-based event-driven systems or build new systems using EDA. In this post, we’ll discuss how these challenges are overcome.

Adaptation to a Different Approach

Solving for many of these challenges requires developers to more aggressively abandon their existing paradigms and preconceptions. Some of what they learned and practiced in building SOA-based applications may apply in an EDA environment, but many run counter to it. They may have difficulty in adapting to the more granular environment of EDA. They may remain more comfortable with their representational state transfer (REST) approach. Their early efforts may be marked by chatty services and continuing to insist that databases are a shared resource.

There is also a natural tendency to avoid the risks created by such radical change as the change from monolithic to microservices and EDA.

Improving and Adding New Skills to Overcome EDA Challenges

Tracing code in a monolithic application is straightforward since all the code for all operations is contained within the monolith. Developers will need to learn the principles of tracing events that occur between services and the reactions those services will produce. A tremendous change of mindset is required to make this transition.

This change of mindset will create a need for the adoption of new tools. Prior tools were not designed to take advantage of new developments such as microservices, containerization, polyglot environments, and more.

In an EDA environment, the greatest development challenge will be identifying dependencies and interactions between various services. Rooting out problems will be impossible without using tools designed to assist.

Governance is Critical

Especially given the enhanced ability to have multiple teams developing different services that will all ultimately need to interoperate, the establishment of standards and a process for assuring adherence will be critical to improving the time and cost of usable products. Nomenclature, variable labels, and others must be carefully aligned between domain owners. Not only will code development benefit from standardization, so do the various databases each service interacts with. Even logging of policies, procedures, and frequency should be aligned within governance.

Also, protocols and standards must be shared across all teams to assure that the application will perform flawlessly.

Aligning tools used between teams is also valuable to overcoming the many challenges associated with event-driven architectures. Team training and orientation should be provided regarding tool selection and application. Continuous monitoring of these processes will be accomplished through consistent evaluation of logs.

Team governance is also required to assure that each team is not only composed of developers and technologists but also of domain experts whose purpose is to keep the services aligned with the business operation objectives of the project. Returning to the mindset issue, EDA development cannot be technology-biased or data-centric. EDA is best employed to respond to business-relevant objectives. One key manifestation here is to focus on database transactions, but EDA should always be focused on business processes.

Revisiting the Major Challenges of EDA

Loosely-coupled events, services, and processes are key components of any EDA strategy. Services and events only become more valuable when the focus is maintained on the business processes they support, and not the databases.

While it may represent something of a leap of faith, business and workflow logic will sooner facilitate development and tracking of EDA code and process flow. Since logic is most often altered by the response to events occurring between services it becomes difficult to follow the logic technologically. It is far simpler to follow the intended workflow in terms of business operations to assure that each event triggers appropriate responses.

The Unknown results that can occur between different microservices is most often analyzed by developers with deep technical knowledge. But for the domain expert, what should happen in the normal flow of business is much more apparent, not really unknown. Pairing their domain expertise of what should happen with the developer who is building the code, is a powerful way of making the unknown known where it counts most, in the services themselves.

The Unforeseen becomes more and more challenging as the ecosystem scales, and is harder to provide contingencies for as undesired results are often not occurring within any one given microservice. A deep understanding of the business processes supported is required to anticipate the unforeseen and provide a more resilient application ready to handle a greater scope of possibilities. One area of particular sensitivity relates to the sequence in which things occur, which may be highly variable. The best response to each possibility in each possible sequence.

When EDA is NOT the Best Solution developers must be able to see and recognize that EDA is not the best solution for any given application. With the proper granularity, the right combination of domain and technical expertise, and the careful identification of all possible events and their responses, EDA enables microservices to become the foundation of a highly interactive, interoperable solution.


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