An explanation of the differences between event-driven architecture and request-response models across key factors like coupling, consistency, and flexibility.
Are you deciding between an Event-Driven Architecture (EDA) and a traditional Request/Response model for your system? This video breaks down the critical differences to help you make the right choice.
We'll compare these two architectural patterns across six key factors: reactivity, coupling, consistency, historical state, flexibility, and data reuse. Using a practical e-commerce storefront example, you'll see the real-world strengths and weaknesses of using Apache Kafka for EDA versus direct communication with REST or RPC.
About Confluent:
Now an IBM company, Confluent was built by the creators of Apache Kafka® to help businesses easily access and use live, streaming data. Its platform manages large flows of data and shares them across an organization in real time. Industries like retail, finance, and manufacturing connect their data, analyze it, and run real-time applications. To learn more, please visit confluent.io
- Intro: EDA vs. Request/Response
- The Storefront Example
- Factor 1: Reactivity
- Factor 2: Coupling in Space and Time
- Factor 3: Consistency (Eventual vs. Strong)
- Factor 4: Historical State
- Factor 5: Architectural Flexibility
- Factor 6: Data Access and Data Reuse
- Summary & Key Takeaways
#ApacheKafka #EventDrivenArchitecture #Microservices #SystemDesign #SoftwareArchitecture
#IBMConfluent
Why it's here
2 people recommend this
What people say. Recommended as a good introductory resource for understanding event-driven architecture patterns.
On “What's your current take on queues and event-driven architecture in general?”
What are you trying to learn about or achieve exactly? Given your lack of experience with the topic, it would seem some cursory google searches on the topic (like this first hit I found on youtube) might get you some basic exposure to patterns in event driven architecture and then enable more focused follow up questions
>Tell about your experience with event-driven architecture, messaging, queues and how you decide when you **must** use them.
You rarely **must** do anything. It's always a question of understanding the trade offs and fitting a solution to your specific needs.
