Event-Driven Architecture Myth Busting — Part 1: Five Common EDA Claims

Here is a claim that I am willing to drop: event-driven architecture (EDA) is filled with myths. Yep, I said it — and that’s a fact! Now that the elephant is out of the room, let me explain. In this blog post, I will be listing a couple of hand-picked claims about event-driven architecture and, you guessed it, I will either bust them or confirm them as fact. Let’s go ahead and delve further into this exploration with our first five EDA claims!

1. I will have to re-design my REST-heavy architecture from scratch to adopt EDA

Poll Results (LinkedIn, Twitter, Reddit):

A digital transformation journey strategy explicitly takes that into account! It simply answers the question of “how can I liberate my already existing architecture with its legacy tools, tech, and protocols to modernize my infrastructure without throwing away what I already have”. Choosing an event broker to support an event-driven architecture implementation that natively supports protocol translation facilitates the adoption in existing architectures. If the event broker of choice natively supports sending/receiving REST messages, you’ll be able to integrate existing RESTful APIs with messaging APIs and protocols like JMS, MQTT, or AMQP without any extra external adapters, connectors, or bridges.

This is an extremely valuable asset to an event broker as it provides the organization with an architecturally simple way to distribute business events (order placed, payment initiated, room booked, etc.) to core APIs/services. And since digital transformation journeys to adopting event-driven architecture is an iterative process, this pattern of protocol translation support is valuable in the long-term as it provides a gradual path for adoption of an event-driven architecture. Check out these resources to see how you can become an event-driven enterprise in 3 steps or implement event-driven architecture in 6 steps.

Therefore, claiming that a complete redesign of a REST-only architecture is inevitable when adopting event-driven architecture is a complete… BUST!

2. APIs are only asynchronous in EDA

Poll Results (LinkedIn, Twitter, Reddit):

A digital transformation journey to adopt event-driven architecture involves the process of event-enabling an already existing architecture. This could include a harmonious interaction between microservices and applications that use synchronous REST-based APIs and other components of the system that incorporate asynchronous message-oriented APIs.

A modern event broker should support both synchronous and asynchronous message exchange patterns. We’ve always heard the famous “it depends” answer when asking any architectural question about the choice of technology stack in an architecture. And it’s true – choosing a synchronous or asynchronous strategy to implement a particular feature or solve a specific problem does depend on the use-case. That’s why it’s so important to acknowledge that event-driven architecture does not replace synchronous call-and-response REST altogether, but complements it.

Hence, the myth that APIs are only asynchronous in event-driven architecture is… BUSTED!

3. Designing EDA involves lots of moving parts

Designing and implementing event-driven system requires a comprehensive strategy, and multiple tools. These tools are used to track all the events in the system, the different payload schemas, the documentation of the events, the versioning of the topics, and – on top of that – visualizing the overall event-driven architecture topology between the different application domains in your system.

Organizations use Microsoft Excel to track event topics, schema registries to track the payload schema, Visio diagrams to visualize the constantly changing event-driven architecture topology, wiki pages to document every moving part, and code repositories to store the application code.

Complete event management toolsets like event portals facilitate the design, documentation and governance of events and event-driven applications allowing easier collaboration between different stakeholders. Similar to an API portal that makes REST-focused application development easier, an event portal is a one-stop-shop for all things EDA, starting from designing topics, defining payload schemas, visualizing the topology, defining the contracts between applications and application domains within the organization, all the way to code generation from leveraging asynchronous API specifications like AsyncAPI.

Hence, the myth that designing event-driven architecture involves many moving parts is…CONFIRMED!

4. An event broker is the only thing you need to implement EDA

Poll Results (LinkedIn, Twitter, Reddit):

When deciding whether to adopt an EDA strategy, architects and developers should look at this decision through a platform lens instead of just evaluating event brokers. Event-driven architecture should be implemented with a toolset that enables data transformation, connectivity to a wide range of event sources, and tracing events through an event mesh that cannot be independently provided by an event broker.

Enabling event-driven architecture requires strategies and tools for documentation; governance to help determine the downstream impact of upcoming changes to apps; events and schemas; and topology visualization of many different microservices, along with the relationship of events connecting applications and application domains.

All this cannot be successfully implemented with a standalone event broker only, so the myth that an event broker are the only thing you need to implement event-driven architecture is… BUSTED!

5. Using Asynchronous API patterns means processing is done “later”

When implementing event-driven architecture, a developer can leverage several message exchange patterns, including “fire-and-forget” and request-reply. The fire-and-forget pattern is useful for keeping logs or events for later processing, such as analytics. On the other hand, the request-reply pattern is known for being inherently synchronous, meaning that further processing is blocked until the initial request is completed. I would even argue that implementing a request-reply behavior using messaging APIs is more powerful than REST APIs (obviously this is a biased opinion given my focus on messaging).

The request-reply pattern can be used in the case of an event consumer needing to request information from another provider, requiring a bi-directional exchange of information. Implementing this pattern involves:

1. A requestor publishing a message on topic A.
2. The message is then received by the provider that subscribed to topic A.
3. A response is then published by the provider on topic B.
4. The response is then received by the original requestor that subscribed on topic B.

Due to the asynchronous nature of the implementation, the requestor can engage in more than one asynchronous request-response conversation at one time.

So, the myth that using an asynchronous API means that processing is only done later is… BUSTED!

Did you enjoy this? Check out Part 2!