@tugcehilal2536
i thiVk there is a miss explanation here 5:01 adding more subscribers doesn't reduce delay: Subscribers are consumers of events. If you add more subscribers to the system, each subscriber will still consume events independently. They don't necessarily share the workload unless the system is designed for load balancing, but more subscribers alone won't reduce the time it takes for any specific event to reach a subscriber. If one subscriber is delayed due to network or processing limitations, adding more subscribers doesn't help that subscriber process events faster.
@joaopedrorocha4790
Feels like the observer pattern but through a network.
@faheemshahidkc
i am so happy to easy this. because i am a self learning software developer. thanks a looot!!!! keep going!
@johningram2153
"Redis is a cache" is one of the biggest myths in IT. It is useful as a cache, among other things, but it tragic how many people think of it as just a caching system. Partially because "memcached", which in fact IS just a cache, was replaced in many cases by Redis, because Redis was better in some ways, for caching, then memcached (and memcached actually remained better than Redis in a couple of ways also). Alas, Redis is a brilliant no-SQL database that does several things supremely well.
@nkulmati
A brief dive into queue-based vs log-based would help to make this more complete (eg rabbitmq vs kafka)
@taskinkhaleque2100
Great explanation. If possible can you pls explain the queue-based vs log-based broker in another video.
@portfedh
I've been using it without knowing with my Esp32 and MQTT. Thanks for the explanation
@Simvetanylen
On an "API driven architecture", you have consistency problems too. When a microservice calls another microservice, they aren't bound to the same transaction (unless using 2PC). Futhermore, it's hard to manage rollbacks in case of rest call failure. The structure can become really fragile easily.
@mundakamaal302
Hi Alex, your videos are precise, short and informative. I am loving it and watching it, however on this specific video, wouldn’t it be great to provide more comparative aspect between messages and event based architecture along with more used cases for each?
@opengeek
Beware that events don't magically decouple your code by itself if you're importing things form either of the two packages you're trying to decouple you're coupling with them. If you use classes that belong to any of the packages you're trying to decouple in the event you're effectively coupling teh two packages anyway. ALso if you're designing you're events in a way that they're conceptually targeting a particular listener instead of being just a signal of something happening (i. e. NotifyOrderDoneEvent vs OrderDoneEvent) you'r conceptually coupling teh event to one of its listeners and doing events for the sake of doing events. Please don't do this because that would jeopardize all your effort to create an event system that is coupled with everything increasing complexity and not delivering any real architectural value.
@marwinsteiner5817
Hi, this is very useful, thank you!
@abhiroopghatak9442
multi producer - consumer case .... this msg queue will be SPOF and if creating multi instance of this queue then consumers will receive multiple duplicate messages which eventually loads the consumer server.
@raminsadeghnasab9310
This is an amazing video you explain like it's super easy. Thank you so much.
@leomysky
Thanks for the video, nice one
@girishhariharan5826
Could you please recommend a book on Event Driven Architecture?
@janardhan2jordan
Great explanation
@lokithor83
very clear and informative.. Thanks Alex..
@wireddeveloper
Does that mean the whole architecture acts like load balancer?
@codewithkashif
Great tutorial! One important question -- Is there any difference between Event Driven Architecture and Reactive Programming?
@hexunlocked