Event-Driven Architecture: What's the sitch?
Alright lets face it, there are alot of content talking about how REST APIs are not the best architectural approach for designing a microservices architecture. I wrote a blog post about My journey to learning EDA that highlights what event-driven architecture is. Whether you are new to 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!
Note: The original and a bit longer log was originally written on: Event-Driven Architecture Myth Busting — Part 1: Five Common EDA Claims
1. I will have to re-design my REST-heavy architecture from scratch to adopt EDA
🤯 MYTH BUSTED!
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 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.
2. APIs are only asynchronous in EDA
🤯 MYTH BUSTED!
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 a harmonious interactions between synchronous and asynchronous APIs is inevitable in a digital transformation journey to adopt EDA.
3. Designing EDA involves lots of moving parts
✅ CONFIRMED!
Yes this is true. Designing and implementing event-driven system requires a comprehensive strategy, and multiple tools. You are dealing with alot of things here: topology visualization, application documentation, curating and cataloging the different topics, defining payload schemas for every published events, defining the interaction between applications, pin-pointing the cascading effects of every change, and ON TOP OF THAT managing access governance!
Phew thats alot! What's the solution? We'll I am presenting you with two solutions:
1️⃣ 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 😅
2️⃣ 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 facilitate the design, documentation and governance of events and event-driven applications allowing easier collaboration between different stakeholders.
4. An event broker is the only thing you need to implement EDA
🤯 MYTH BUSTED!
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!
5. Using Asynchronous API patterns means processing is done “later”
🤯 MYTH BUSTED!
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 behaviour is a proof that asynchronous APIs does not always mean process later.
SHOW ME MORE!
Did you enjoy reading this? Do you want more details about every claim? Say no more! Check out my original blog post here: Event-Driven Architecture Myth Busting — Part 1: Five Common EDA Claims
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.
P3ace Out ✌️
P.S Follow me on The Twitter for more content @tweettamimi
Top comments (0)