4 Key Types of Event-Driven Architecture

[@alexanderspiegel6747]

These are very interesting topics. Please continue

[@jacklynetsai]

Super helpful!!

[@JogoShugh]

Fantastic, thank you! Currently reading your book too. And I mean I am recording myself narrating your book, lol. Of course, not for anyone but me, but it really helps my brain conceptualize and retain the information better.

[@cowliqour1051]

Good stuff Adam!

[@karthikbm3307]

AWESOME AWESOME!!!

[@oscarluizoliveira]

Congratulations on the content Adam, this area of ​​technology of ours is very complicated, with many of the same terms having different meanings depending on the context, I'm studying postgraduate studies in software architecture and it drives me crazy. Taking advantage, when we talk about an ephemeral form without retention, we are referring to a pattern where events are processed in real time and are not stored for later consultation, is that it?

[@artmusic6937]

cant you use kafka for app internal communication or queues aswell? or is this not recommended?

[@yuriir3219]

Nothing stops you from doing it, however it all depends on the use case. For example, if your app (assuming you’re referring to a ‘service’) is a monolith running as a single instance (no horizontal scaling anticipated or supported), then in-memory queue would be a first option to consider - in general it’s simpler and cheaper. However if a service runs in multiple instances and you already have Kafka as part of your infrastructure - it’s perfectly fine to set up inter-instance communication via Kafka. Here’s a couple of examples I’ve seen in real production: - Task breakdown: receive an external event, split it into N atomic independent pieces and sent to all service instances to parallelize work (shared consumer group) - State propagation (local cache): instance receiving a write forwards it into an internal topic, all instances of the service use unique consumer groups to receive copy of this message (fan-out) - analogue of sticky sessions: relying on partitioning algorithm (ex: userId) to make sure all events belonging to the same logical entity (here - user) are getting processed by the same service instance (be careful with rebalancing and choosing right partition key)

[@ShimoriUta77]

Bro how do you write mirrored like that on glass?

[@emont]

so, EDA is like RAG but source information could be real time outputs? let say I could make a LLM to ask to a management monitoring system: what is the current interfaces that are flapping in my network ?

[@maciekskontakt]

Good explanation - not quite correct examples. ESB is not about ephemeral messaging (if you worked with it you would know not from theory - I did for years). Ephemeral is topic related. However, Apache Camel ESB with Apache MQ GUARANTEES delivery even on topic provided that subscriber subscribed once (it is lost in two cases: not subscribed first time or you exceed parameters of how for long it is stored).

[@maciekskontakt]

@@ConfluentDeveloperRelations Hi Adam. I liked your explanation very much. I was reading and listening to Confluent and watching and learning Kafka for last years (wondering if you should somehow join Confluent perhaps ;) I even found one problem on state race condition in microservices if someone is not careful enough in designing and implementation with Kafka events (related to Saga pattern). But Kafka for many is the way to go and I was on architecture while in Fiserv that uses Kafka in AWS for credit cards (very nice design, but not mine). So Kafka and Confluent works are very close to my heart, but I hate to use my prior intimate knowledge with other systems to point some gaps. Thanks for correction.

[@edersonduarte4696]

Hello from Brazil

[@teolcd]

EDA is by nature the most powerful approach for distributed systems. However, this video is about structure and a bit of behavior pattern. If you need more info, you will need to research QoS, versioning, schema ...