Event-Driven Architectures: 5 Myths
Event-driven architectures are filled with claims that may or may not be true. This article is the first to discuss EDA Myths that are common in the industry.
Join the DZone community and get the full member experience.Join For Free
Event-Driven Architecture: Bust or Fact?
Alright, let's face it—there is a lot of content talking about how REST vs messaging APIs and how one is more fir than the other for a microservices architecture design. I wrote a blog post about My journey to learning EDA that highlights what event-driven architecture is. Whether you are new to event-driven architecture (EDA) or have some background with it via dabbling with gRPC, kafka, rabbitMQ, Solace, or whatever messaging API, I am here to share with you 5 claims about EDA that I will be busting or confirming.
I Will Have to Re-Design My Rest-Heavy Architecture From Scratch To Adopt EDA
Advanced event brokers allow for protocol translation within the broker. What does this mean you might ask? Well, it is very common in any software architecture design approach to have a polyglot of protocols and APIs in an application. Whether you are using REST, or different messaging protocols (MQTT, AMQP, Solace, Kafka...etc) you would want your different microservices to communicate with each other.
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.
Therefore, we can't claim that a complete overhaul of a REST-only architecture is a must to implement EDA.
APIs Are Only Asynchronous in EDA
Implementing EDA in an already existing architecture involves the process of event-enabling the underlying technology. Event-driven architecture does not replace synchronous call-and-response REST altogether but complements it.
Having harmonious interactions between synchronous and asynchronous APIs is inevitable in a digital transformation journey to adopt EDA.
Designing EDA Involves Lots of Moving Parts
Yes, this is true. Designing and implementing an event-driven system requires a comprehensive strategy and multiple tools. You are dealing with a lot of things here: topology visualization, application documentation, curating and cataloging the different topics, defining payload schemas for every published event, defining the interaction between applications, pin-pointing the cascading effects of *every* change, and on top of that, managing access governance!
Phew, that's a lot! What's the solution? We'll I am presenting you with two solutions:
- Use the right tools! Microsoft Excel to track event topics, Wiki pages like confluence to document the payload schemas, Git to version control the different schema versions for every topic, Visio diagrams to visualize the constantly changing event-driven architecture topology, and finally, a communication tool to communicate the changes. And oh wait, one last thing, a project manager to manage all this.
- Use an Event Portal! Similar to how REST APIs have an API portal to document and manage the API, Asynchronous Event APIs have an Event Portal that facilitates the design, documentation, and governance of events and event-driven applications allowing easier collaboration between different stakeholders.
An Event Broker Is the Only Thing You Need To Implement EDA
It's important to know that when working on implementing an event-driven architecture the approach should be looked at as a holistic platform composed of a list of tools instead of just one tool (i.e. Event Broker). This is a common misconception that EDA is associated with an event broker only.
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.
And that is why this statement is a myth!
Using Asynchronous API Patterns Means Processing Is Done Later
I would definitely recommend looking up message exchange patterns (MEP) in event-driven architecture. When doing so, you will see that request-reply is one of the MEPs in EDA which involves an event consumer requesting information from another provider resulting in a bi-directional exchange of information. This behavior is proof that asynchronous APIs do not always mean process later.
Do you have OTHER claims that you would like me to bust or confirm? Comment down below and I would be more than happy to hear your input and thoughts on this.
Published at DZone with permission of Tamimi Ahmad. See the original article here.
Opinions expressed by DZone contributors are their own.