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.
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
MYTH
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
MYTH
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
#microservice #realtime #event-driven #myth
