Hi! Nice explanation! I appreciate the balanced approach to discussing the pros and cons of event-driven architecture. It's important to consider both sides before making a decision, especially eventual consistency, and this video did a great job of laying that out!
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.
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?
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.
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.
Great video! One questing about 3:53: Wouldn't you have the same kind of reliability if you installed a broker between the two services in an event driven architecture, as this would introduce asynchronous execution?
Yes if reliability is your only concern then an event broker would work too. Event-driven architecture does tend to change how you view the architecture of your whole application.
Wow this is the easiest explainer of event driven architecture I've seen! Thank you so much. I used to work with WCF and MSMQ and I feel it's kinda the same except for the fact there's no broker that pushes the events to consumers. I'm kinda curious what the event message looks like in the event driven architecture way of things.
You're very welcome! The event messages can vary quite depending on who is implementing them. Some prefer small messages that just mention that an event occurred. This therefore requires the consumer to call the producer to get more information. Others create quite detailed events that contain all the information that a user would need. As a producer, it can be a bit of a balancing act between having to constantly add new information to an event which is likely also available via API or having consumers also call your API for every event that comes in.
@@alexhyettdev thank you so much for detailing that! The fun in there is choosing what approach to take then. Might need more experience to find out what kind of event messages to send (from very verbose to just a request to have them poll from the producer the related info)
It mostly comes down to performance. If you need to process hundreds or thousands of events a second you don't want to have to go off to an API to get more information.
Hello, great video. I am fairly new to this, would you use EDA for this use case: due to Regulatory reasons the company needs to forward emails to certain recipients in the event of an agree-upon trigger. I am sorry if the question is too specific. keep up the good work.
Thanks. Yes, that is quite specific and a difficult one to answer without knowing the system in detail. In theory, you could raise an EmailSent event but you would still need to read the message for the trigger word and then forward it.
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.
I'm not sure which part you're unsure of so I'll over-answer. A queue is being used to move the data, in the form of a message. Queues are a way of decoupling components - they don't have to know about each other, only the queue. Once a message is processed it's removed from the queue - so you can do things like guarantee it's only processed once, etc. Does that help?
An orchestrator handles everything including the communication back to the parent service. The event broker on the other hand just passes events along for services that are subscribed. Orchestration is pretty much the opposite of event driven architecture.
Nice video, really liked it, but I get the feeling you dragged "eventual consistency" kicking and screaming into your example of services being slow to pick up events. It probably doesn't belong there, as that term is more about data consistency between different databases ... even though it could be related in some scenarios I guess.
Haha I love the analogy. Yes it definitely depends on the scenario. A lot of the time when I have used EDA is where I have had reporting systems fed from it hence it coming up.
It is just a case of scaling up the number of subscribers. Of course, this can have its own limitations. There might be a bottleneck downstream that caps how many events you can process. This is especially true if each of those subscribers is writing to the same database. This is where you need to start looking at things such as database sharding or caching all the reads.
I like the explanation but one thing that i so much wanted but it seems lacking in the video is showing us how it's done or where it's used in real life applications, this is what makes the video relatable not just telling us the advantages and disadvantages. How do I know ad and disadv when i don't even know how it works in a real life application Great video tho
Hi! Nice explanation! I appreciate the balanced approach to discussing the pros and cons of event-driven architecture. It's important to consider both sides before making a decision, especially eventual consistency, and this video did a great job of laying that out!
Thank you! I am glad you enjoyed it!
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.
i am so happy to easy this. because i am a self learning software developer. thanks a looot!!!!
keep going!
Feels like the observer pattern but through a network.
A brief dive into queue-based vs log-based would help to make this more complete (eg rabbitmq vs kafka)
Sure I will add it to the list and I can do a video on that in the future.
I've been using it without knowing with my Esp32 and MQTT. Thanks for the explanation
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?
Thank you! Yes, I will make sure I do some videos on that in the future. I didn't want to cram too much in my first video on the topic.
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.
Thanks for the video, nice one
This is an amazing video you explain like it's super easy. Thank you so much.
Amazing videos man, keep them coming. Thanks!
thank you very much for covering so many aspects... so well.
very clear and informative.. Thanks Alex..
Thank you very much. Excellent explanation.
Great explanation
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.
Yes they both have consistency problems. I am not sure anyone has come up with a way around that without causing scaling problems.
@@alexhyettdev There is no solution on distributed environnements (CAP theorem)
Thank you for the amazing explanation
Glad it was helpful!
Great video! One questing about 3:53: Wouldn't you have the same kind of reliability if you installed a broker between the two services in an event driven architecture, as this would introduce asynchronous execution?
Yes if reliability is your only concern then an event broker would work too. Event-driven architecture does tend to change how you view the architecture of your whole application.
Great explanation, thank you !
Wow this is the easiest explainer of event driven architecture I've seen! Thank you so much. I used to work with WCF and MSMQ and I feel it's kinda the same except for the fact there's no broker that pushes the events to consumers. I'm kinda curious what the event message looks like in the event driven architecture way of things.
You're very welcome! The event messages can vary quite depending on who is implementing them. Some prefer small messages that just mention that an event occurred. This therefore requires the consumer to call the producer to get more information. Others create quite detailed events that contain all the information that a user would need.
As a producer, it can be a bit of a balancing act between having to constantly add new information to an event which is likely also available via API or having consumers also call your API for every event that comes in.
@@alexhyettdev thank you so much for detailing that! The fun in there is choosing what approach to take then. Might need more experience to find out what kind of event messages to send (from very verbose to just a request to have them poll from the producer the related info)
It mostly comes down to performance. If you need to process hundreds or thousands of events a second you don't want to have to go off to an API to get more information.
simle and great explanation
This was insanely good...👏
Hello, great video. I am fairly new to this, would you use EDA for this use case:
due to Regulatory reasons the company needs to forward emails to certain recipients in the event of an agree-upon trigger. I am sorry if the question is too specific. keep up the good work.
Thanks. Yes, that is quite specific and a difficult one to answer without knowing the system in detail. In theory, you could raise an EmailSent event but you would still need to read the message for the trigger word and then forward it.
Good and very detailed explanation.
This was an excellent video, thank you! Subscribed. :)
can you suppress that background barking kind of sound that emits from your laptop when you are running thru the slides
Thank you Alex. Your explanation is quite eloquent and comprehensive. God bless you
I love this explanation.. Great guy
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.
Thank you for this amazing video
Could you please recommend a book on Event Driven Architecture?
Great video!
Does that mean the whole architecture acts like load balancer?
i couldnt understand 1:22-1:30, can you please elaborate on that?
I'm not sure which part you're unsure of so I'll over-answer. A queue is being used to move the data, in the form of a message. Queues are a way of decoupling components - they don't have to know about each other, only the queue. Once a message is processed it's removed from the queue - so you can do things like guarantee it's only processed once, etc. Does that help?
What’re examples of event services.. azure redis cache??
Great tutorial! One important question -- Is there any difference between Event Driven Architecture and Reactive Programming?
Not really, reactive programming is generally implemented using an event based system.
Excellent video
Great content! But this sound effect every time when slide appears is suuuuuuper annoying...
Same
Noted!
Keep up the good work! @@alexhyettdev
I like it actually
I didn’t start feeling annoyed until you said that 😅
Very clear thank you! +1 subscriber! :)
Thank you, I am glad it was useful.
You could decrease the background music
Won't broker in event driven architecture is similar to Orchestrator ?
An orchestrator handles everything including the communication back to the parent service. The event broker on the other hand just passes events along for services that are subscribed. Orchestration is pretty much the opposite of event driven architecture.
Great video.
Nice video, really liked it, but I get the feeling you dragged "eventual consistency" kicking and screaming into your example of services being slow to pick up events. It probably doesn't belong there, as that term is more about data consistency between different databases ... even though it could be related in some scenarios I guess.
Haha I love the analogy. Yes it definitely depends on the scenario. A lot of the time when I have used EDA is where I have had reporting systems fed from it hence it coming up.
thank you!
Event metadata are sent in messages! Events are something that happens in systems. They aren't something you can send..
What if a subscriber can't keep up with the events produced by the producer?
It is just a case of scaling up the number of subscribers. Of course, this can have its own limitations. There might be a bottleneck downstream that caps how many events you can process. This is especially true if each of those subscribers is writing to the same database. This is where you need to start looking at things such as database sharding or caching all the reads.
@@alexhyettdev Thanks, great video by the way!
@@MateuszKupiniak Thanks!
I like the explanation but one thing that i so much wanted but it seems lacking in the video is showing us how it's done or where it's used in real life applications, this is what makes the video relatable not just telling us the advantages and disadvantages. How do I know ad and disadv when i don't even know how it works in a real life application
Great video tho
Could you please drop the "welcome back to the channel" bit?! It's so cringe. Just a hello will do.
Wtf, I am literally speechless
Is it that annoying? That's just a damn four words more!
I am not sure if that emoji is pointing upwards or giving me the finger 🤣. I hope it’s the former!
wonderful explanation