i am so happy to easy this. because i am a self learning software developer. thanks a looot!!!! keep going!

Amazing videos man, keep them coming. Thanks!

thank you very much for covering so many aspects... so well.

Great explanation, thank you !

Good and very detailed explanation.

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!

@alexhyettdev

10 ай бұрын

Thank you! I am glad you enjoyed it!

This was an excellent video, thank you! Subscribed. :)

Great video!

Thank you for this amazing video

I love this explanation.. Great guy

Feels like the observer pattern but through a network.

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?

@alexhyettdev

Жыл бұрын

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.

Thank you for the amazing explanation

@alexhyettdev

5 ай бұрын

Glad it was helpful!

Great video.

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.

@alexhyettdev

9 ай бұрын

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.

@takatakboy

9 ай бұрын

@@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)

@alexhyettdev

9 ай бұрын

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.

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?

@alexhyettdev

9 ай бұрын

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.

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.

@alexhyettdev

10 ай бұрын

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.

A brief dive into queue-based vs log-based would help to make this more complete (eg rabbitmq vs kafka)

@alexhyettdev

7 ай бұрын

Sure I will add it to the list and I can do a video on that in the future.

can you suppress that background barking kind of sound that emits from your laptop when you are running thru the slides

Great tutorial! One important question -- Is there any difference between Event Driven Architecture and Reactive Programming?

@alexhyettdev

10 ай бұрын

Not really, reactive programming is generally implemented using an event based system.

Very clear thank you! +1 subscriber! :)

@alexhyettdev

7 ай бұрын

Thank you, I am glad it was useful.

thank you!

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.

@alexhyettdev

11 ай бұрын

Yes they both have consistency problems. I am not sure anyone has come up with a way around that without causing scaling problems.

@Simvetanylen

11 ай бұрын

@@alexhyettdev There is no solution on distributed environnements (CAP theorem)

i couldnt understand 1:22-1:30, can you please elaborate on that?

Won't broker in event driven architecture is similar to Orchestrator ?

@alexhyettdev

Жыл бұрын

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 content! But this sound effect every time when slide appears is suuuuuuper annoying...

@shafiq_ramli

5 ай бұрын

Same

@alexhyettdev

5 ай бұрын

Noted!

@shafiq_ramli

5 ай бұрын

Keep up the good work! @@alexhyettdev

@Vitoria-rv7bx

4 ай бұрын

I like it actually

@arielguzman2875

3 ай бұрын

I didn’t start feeling annoyed until you said that 😅

You could decrease the background music

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.

@alexhyettdev

7 ай бұрын

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.

What if a subscriber can't keep up with the events produced by the producer?

@alexhyettdev

Жыл бұрын

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.

@user-mx8ij4tk6i

Жыл бұрын

@@alexhyettdev Thanks, great video by the way!

@alexhyettdev

Жыл бұрын

@@user-mx8ij4tk6i 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

@alexhyettdev

Жыл бұрын

I am not sure if that emoji is pointing upwards or giving me the finger 🤣. I hope it’s the former!