5 Insights on Implementing Event-Driven Architecture

There are many challenges to overcome when adapting event-driven architecture (EDA). This is often a very complex project, especially when you have to deal with legacy systems. Here are my personal five tips that will guide you towards a successful implementation.

1. Make sure everyone accepts the new strategy

The first move towards an event-driven architecture (EDA) often begins within the development teams. For them, it quickly becomes clear that an event-driven approach is the best way to support the company’s growth.

However, it is not uncommon for these initiatives to face the opposite requirements from other departments. The rest of the company often prefers a faster implementation as opposed to a sustainable one and doesn’t understand the event-driven approach.

It’s important to educate them on the benefits of the new architecture in this initial phase. It should be finalized in an official announcement on the new integration strategy. It has to earn the full support of the key stakeholders such as the CTO, CIO, etc. You need everyone to be on the same page.

2. Remember that an event-driven architecture doesn’t replace APIs

There are still countless scenarios that speak in favor of an API. For example, if it’s a synchronous process that requires a direct response, the API is a far better choice. You should thoroughly examine your needs and the pros and cons of both of them.

3. Keep the complexity to a minimum

When you integrate multiple legacy systems, the complexity and the number of events can increase exponentially. Changing tracking, binary data, GDPR, etc. can quickly pose major challenges for your integration project.

To prevent chaos, you should consider the “keep it simple, stupid” (KISS) principle. It’s often helped me to take a step back, rethink the process, and optimize it.

4. Establish clear practices for event governance

When introducing EDA, you should also think about establishing certain practices and processes in order to keep your architecture clean in the long term. Otherwise, incorrect data input from third-party systems can result in a disaster.

You might also create a cross-team “event council” to coordinate these issues. It’s proven to be a very practical way to keep it under control.

5. Keep business logic away from event subscribers

It is not uncommon for me to come across projects in which event subscribers have been misused to implement business logic. It’s a bad practice. Without exception, business logic should be outsourced to microservices or software designed for this purpose. This is the only way to guarantee clear responsibilities and good maintainability when the environment is scaled up.