Hey folks!👋 Want to have hands-on practice on these concepts? 🤓 Try out CodeCrafters.io we have partnered and you can get 40% off 💸with this link: app.codecrafters.io/join?via=DevStory They have great hands-on tutorials and easy to get up to speed with complex systems. Check them out!
Event driven architecture Event - something that happened - immutable or can't be changed. - can be communicated or implemented through event notification. Command - request, or order, expects a response - can be communicated or implemented through message. Event Driven architecture - also referred to as publisher-subscriber model. Three Components 1. Producer 2. Broker 3. Consumer Producer -> Broker -> Consumer - a producer creates events that are redirected by a broker into the right consumer. - consumers will react to this event and execute things they need to execute. Benefits - decoupling (not dependent to other services) - dependency inversion - scalability Traditional architecture Service1 -> Service Event driven architecture Service1 -> Event -> Service2 - in an event driven architecture, service1 doesn't need to know about service2 vice versa. - they communicate through events: producing and consuming events. Events Persistence - using a broker. ex kafka - previously you need service1 and service2 to be both online and pass data, but having a broker enables events to be persisted. in other words brokers can be used a temporary storage if there is a situation that the consumer is down, once the consumer is online again the data can be send to the consumer again. traditional architecture Service1 -> Service2 Service1 -> Broker (havings events) -> Service2 When to use 1. Scalability is more important than performance. 2. Data replication/Parallel Processing - you need the same information in multiple systems. - if you multiple services (subscribers) that needs to be process or executed at the same time.
Its the first video I have ever seen that showed pros and cons of Event Driven Architecture. This is perfect example that one size doesn't fit all. Awesome content and thank you so much.
I arrived to learn about software architecture and I find more than just that. Thanks! Cristhian. It's kind of difficult for me to understand some concepts but I don't care, I just want to learn even if the learning curve is very steep.
Glad you are enjoying the channel! If there's any specific topic you might be interested in or anything I can do to make it more digestible let me know :)
I really liked the way you have organized the content and made it very crisp and clear for anybody to have a high level knowledge or those who want to recap just before interviews. A very useful series.
Yes I prefer to differentiate between the event and command notions, since events are simply a notification that can trigger something else asynchronously while a command can be rejected and the commander must receive the rejection code and the cause of his rejection
I'm planning to take CS in college and your videos are really inspiring me to become a Software Architect thanks a lot!! Can't wait to see more of your vids!!!
Thank you for sharing your knowledge in such an amazing way. I would like to suggest you put all these concepts into practice, implementing it in some language you prefer. I think that would be great.
thanks for this video series. What would be nice to see is that if you could explain different architecture Patterns and go for a sample project and select a pattern with explaining reason and implement the architecture with technology and create at the end a very simple product. Let's say a web application built through cloud and could also be implemented by watchers by watching your video. Then another example another pattern implementation. With those key samples, the one who has interest in learning software architecture can build his/her understanding and build his/her own knowledge about software architecture and implementation of it.
Great video, thanks a lot! I just wish audio was a little bit clearer. Since I'm not a native english speaker I had trouble understanding some parts. I tend to dislike videos with background music for the name reason. Bus still amazing. Moving on to the next parts!
Oh I try also to have subtitles in other languages and fix the close captioning to help in that sense, but I'll take the feedback also for new videos. Thanks!
Thank you very much! But incomparable Martin Fowler is a legend and this video just takes a small part of what he he has talked about EDA. Thank you though! :) Hope you continue enjoying the series
Basically a broker is a system that is able to pass events (Kafka being an example). It's not only a queue as a broker can have different ways to do so (topics too for example) but it does follow the publish subscribe pattern. Here's a definition: solace.com/what-is-an-event-broker/. Hope is clearer :)
If I understand your video correctly, EDA uses events while API's use commands. How does using API's fit in this EDA story? It is something completely different, or can both be combined? (If so, are there brokers able to both: 1) receive events, queue them, make them available to other services, and 2) maintain an inventory of "API locations" and call the respective API and redirect the response back to the original requester.)
So there are different things here. 1) API is Application Programming Interface. It's basically a contract for your app. So Events can be part of the API. 2) I think you meant rest/rpc apis which most are synchronous / command like executions. And that's the main difference with EDA. You can implement some type of EDA via wev by using technology like websockets. In a local machine tou can also implement EDA by having something like NodeJs' Event Loop, it having a process periodically check if there are events for it to process. The main takeaway here is that in EDA the communication is asynchronous and the coupling is low, so it is indifferent to the underlying technology (can ve Kafka, http, a process, etc). The "calling application" doesn't know anything about the application that will end up executing the task. And the executing application processes it whenever it receives the event. Hope is clearer :)
This was a great video.. thanks!! One question- you mention that there isn't a single point of failure with EDA. But isn't the broker in your diagram a single point of failure? If that goes down, the rest of the system is also impacted right? The services themselves are up and running but with no events, they will not be processing anything.
Hi! Sorry for taking long to get back to you. This is a good question! Thanks for asking. So in summary, in any distributed system you face the issue of any component being able to fail (technically in non-distributed systems too, but it would make the whole system fail). There are things that can make the whole systems fail, think for example: the network and electricity. If those go down, so does your system. But network or electricity are typically not considered a single point of failure. There are mechanisms that allow to make it more reliable, even when they can fail (redundancy, partitioning, batteries, etc). Same thing happens with the broker. A message broker is typically a system that is very efficient and reliable to handle _just_ message passing. It typically is a distributed system with multiple nodes, replication, and reliability considerations that make it highly available. Of course it can happen that it goes down and take all the communication between services too, but typically this risk is highly mitigated. I found this article from Ciaran O'Donnell that might help clarify it a bit more: ciaranodonnell.dev/posts/message-broker-as-spof/ There's also the Fundamentals of Software Architecture book that has a chapter on EDA where it explains it (amzn.to/3HSKYXC *) Please let me know if it isn't clear :) And again, thanks for watching! * Disclaimer, I _may_ receive some payment from Amazon if you go through this link and buy the book at no additional cost to you.
Thanks for your great sharing. Since i'm very junior and i'm preparing system design for interview, I'm just wondering what doest event-driven play a role in system design or there are two totally difference concepts
In the example where a response comes back to the user after confirming payment, how would you route that response back to the user? Are there any options beyond polling from the frontend or using a web socket (which makes your server stateful)?
Not much else. So basically there are two ways from the client: pull (polling) or have a open connection to receive the message (websockets, SSE, http2 type connections and the like). You can have ways to notify the client via an intermediate service. Even having a websockets might be fine if you are able to restablish the connection in case of failures.
I have a question about the single point of failure part, Doesn’t the broker then become the single point of failure ? If it’s down then no event can be sent or received ? If so, how can we say that this approach solve the problem of having a single point of failure ?
Hi! Sorry for taking so long to reply, this is a good question, I already answered it in another comment but RUclips doesn't allow me to link it, so I copy here the same answer :D So in summary, in any distributed system you face the issue of any component being able to fail (technically in non-distributed systems too, but it would make the whole system fail). There are things that can make the whole systems fail, think for example: the network and electricity. If those go down, so does your system. But network or electricity are typically not considered a single point of failure. There are mechanisms that allow to make it more reliable, even when they can fail (redundancy, partitioning, batteries, etc). Same thing happens with the broker. A message broker is typically a system that is very efficient and reliable to handle just message passing. It typically is a distributed system with multiple nodes, replication, and reliability considerations that make it highly available. Of course it can happen that it goes down and take all the communication between services too, but typically this risk is highly mitigated. I found this article from Ciaran O'Donnell that might help clarify it a bit more: ciaranodonnell.dev/posts/message-broker-as-spof/ There's also the Fundamentals of Software Architecture book that has a chapter on EDA where it explains it (amzn.to/3HSKYXC *) Please let me know if it isn't clear :) And again, thanks for watching! * Disclaimer, I may receive some payment from Amazon if you go through this link and buy the book at no additional cost to you.
@ComputerWhisperer, why may I choose Event-Driven Architecture instead of Layered Architecture, which both scalable and, as I see, Layered Architecture provides even better performance?
Depending on the use cases sometimes event driven can be more scalable and have better throughput. For example, in bidding systems, online multiplayer games or even Twitter or feed-like systems. The type and amount of data is better processed in an event driven model there. There are some other cases that are less intuitive at first like web servers based on Netty or NodeJs where an async / event driven model takes advantage of the very slow processing of input/output of a connection. Hope it's s bit clearer if it's not I can explain more. Just as a final thought: layered and event driven are not opposed. You can have layered AND event driven systems (for example, web frameworks).
Great question! The answer could be really long and become more of a discussion but will try to be concise. When you use distributed systems there's always a hit in performance compared to doing the same job in a single machine. Same happens for example in a machine with single thread/single process vs multiple processes. There's an overhead of: having to deploy more resources, greater latency in network communication (vs in memory) and serialization/deserialization among other things. Of course distributed systems can help improve a system's overall performance in other ways: having load balancing and parallelizing tasks, as well as other capabilities like (potentially) better maintainability, and more robustness. But if you could have a big machine that never goes down and it's able to parallelize jobs, it will more certainly be more performant than a distributed system. Add to that that in event driven architectures you need a message/event broker system in the middle between every system. So any communication between a Service A and a Service B has to go to an intermediate Service C which is a broker. As fast as the broker can be it adds some overhead and it will take a hit on performance. There are things to handle like: how to make sure events are not written/read twice? what happens if the broker goes down? and many of these decisions add to the overall performance. Is this something important? Should you discard EDA completely or use it always? It depends a lot on the context. It could be that scalability is more important in your system than performance for example in which case EDA tends to be a good option, or it could be the other way: maybe your system just need to respond within a very tight bound of ms and you're actually not planning to scale much. So at the end it depends a lot on the needs of your project.
Could you help me explain more about 2 points in details: the benefits of "loosely coupling" and "dependency inversion" (some examples in real life about the difficulties if we don't use EDA and how EDA solves in these examples) when we use EDA? For example (Service A Service B C D directly) vs (Service A message broker Service B C D): - If I use a message broker, Service A won't have to care what Service B (or C D) is, Service A just needs to send an event, and Service B, C, D just need to receive, but I still have to configure the message broker so that it can be aware of the services if we have to change the endpoints. - If the customers ask for requirement changes (input or output changes), there will be a high chance that all services related to the functionality (service A, B, C, D in this example) will have to change - If one service is down (because of failure or deployment time), the others still can be online, but the overall functionality won't work properly, because one service requires all other services to work in order to achieve the goal These are the questions that I've been having a headache for a long time... Could you help me clarify and suggest me some best resources related to this field (microservices, distributed system, event-driven architecture, DDD). I wish you the best Christian.
1. You only have to configure the message broker yes, after that you can just plug services into that broker, and as long as all services correctly implements the Events (as in a contract) they are ready to go 2. You always have to change software if you get new requirements, loose coupling doesnt change that, but it can make it easier. You can take down Service A and substitute it with a new service without changing anything else in your overall system / architechture, as long as the new service has properly implemented the required Events (contracts) 3. Correct, if all your use cases needs all services to be online, then your system wont work. But in best case scenario, some use cases will still work, despite one service being down. It is at this point you might load balance and have multiple instances of the same service running, to counteract system failures due to just one service instance going down. Rememeber, EDA coupled with microservices makes your system insanely scalable and resiliant.
It depends. If you are waiting for a response typically event driven architecture is not the best approach. EDA works best for asynchronous communication (when you don't expect an answer). In the case of waiting for an answer you are looking for synchronous communication or request/reply patterns. Of course you can implement it also with EDA but you have to deal with more complexity. So in the case of web requiring an answer my suggestion would be not to use EDA or change the behavior on the web to be async.
I like this video and its good but on some places your explanation is very fast and its hard to understand. Kindly slow down the explanation way which will help us to understand clearly. Thanks for this video.
Oh sad to hear that. I found out actually the opposite. If you want to try, my first videos (algorithms) didn't have any and it was harder to focus I'd say (same for other videos online). I can try lowering a bit more the background music though so it's less distracting. Or maybe having some parts of the video without it. Do you think that'll help?
It's related. I mean partially as you implement observer/observable pattern with an event driven architecture. But you also implement other patterns like event sourcing with it.
consistency part is little not clear , as when you want to have something like happens before relationship , you might want to use chain of events. and now your system it consistent.
If I get the question right, I meant eventually consistent. So when you do a transaction or request/reply all systems are seeing the same information after the operation was executed. With event driven a system sends an event and the other system will read it at one point in the future. If multiple systems are reading the event they may do so at different times
Hey, your audio is way to quiet - i had to turn my speakers all the way up to 100% to hear your voice. Please consider turning the master volume up next time while mastering your videos (its easier to turn the volume down a little rather then having to turn the speakers up to 100% and having to adjust volume for all other running applications)
Thanks! May I ask you on which device are you listening it? Some people have reported it but I've tested in many devices (android phones, tv and desktop) and everything seems to fine. In my latest videos I've been increasing a bit more the volume just in case
If you are like me and followed the playlist from the beginning, you might get confused about Layered architecture and how did event driven architecture come into the picture. Here is a link that I found helpful: www.ibm.com/cloud/blog/four-architecture-choices-for-application-development
Oh this is a great article. Thanks for sharing! Sorry it was a bit confusing. It's actually 2 series of videos and are related but not continuos though. But the article you shared connects them nicely!
Hey folks!👋 Want to have hands-on practice on these concepts? 🤓
Try out CodeCrafters.io we have partnered and you can get 40% off 💸with this link: app.codecrafters.io/join?via=DevStory
They have great hands-on tutorials and easy to get up to speed with complex systems. Check them out!
Event driven architecture
Event - something that happened
- immutable or can't be changed.
- can be communicated or implemented through event notification.
Command - request, or order, expects a response
- can be communicated or implemented through message.
Event Driven architecture - also referred to as publisher-subscriber model.
Three Components
1. Producer
2. Broker
3. Consumer
Producer -> Broker -> Consumer
- a producer creates events that are redirected by a broker into the right consumer.
- consumers will react to this event and execute things they need to execute.
Benefits
- decoupling (not dependent to other services)
- dependency inversion
- scalability
Traditional architecture
Service1 -> Service
Event driven architecture
Service1 -> Event -> Service2
- in an event driven architecture, service1 doesn't need to know about service2 vice versa.
- they communicate through events: producing and consuming events.
Events Persistence
- using a broker. ex kafka
- previously you need service1 and service2 to be both online and pass data, but
having a broker enables events to be persisted. in other words brokers can be used a temporary storage if there is a situation that the consumer is down, once the consumer is online again the data can be send to the consumer again.
traditional architecture
Service1 -> Service2
Service1 -> Broker (havings events) -> Service2
When to use
1. Scalability is more important than performance.
2. Data replication/Parallel Processing - you need the same information in multiple systems.
- if you multiple services (subscribers) that needs to be process or executed at the same time.
What a useful sumary for us! Thanks a lot
Its the first video I have ever seen that showed pros and cons of Event Driven Architecture. This is perfect example that one size doesn't fit all. Awesome content and thank you so much.
Thank you! Glad it was so useful!
I arrived to learn about software architecture and I find more than just that. Thanks! Cristhian. It's kind of difficult for me to understand some concepts but I don't care, I just want to learn even if the learning curve is very steep.
Glad you are enjoying the channel! If there's any specific topic you might be interested in or anything I can do to make it more digestible let me know :)
I really liked the way you have organized the content and made it very crisp and clear for anybody to have a high level knowledge or those who want to recap just before interviews. A very useful series.
Glad it helped! Thanks for the feedback! :)
Yes I prefer to differentiate between the event and command notions, since events are simply a notification that can trigger something else asynchronously while a command can be rejected and the commander must receive the rejection code and the cause of his rejection
action packed 10 min, very nice explanation characteristics of EDA and when to use and not use
Glad you liked it!
I'm planning to take CS in college and your videos are really inspiring me to become a Software Architect thanks a lot!! Can't wait to see more of your vids!!!
Glad they have been inspiring :)
@@ADevStory can you do a series too about being a Cloud Engineer/Architect?
@@gabriellebeduya2063 it's a bit farther away for me, but maybe in the future I can do one :) thanks for recommending it.
Definitely most easy to understand and best presented series on system design
Oh thank you!
These videos are the best videos for starters. Also good for experienced folks. Thanks for the amazing content.
Thank you! Glad you found it useful!
I've just seen all the 3 videos of this series. Thanks a lot.
You're very welcome!
I dont know much of CS and this helped me a lot! Taking Azure Dev Associate certification
Amazing! Good luck in your certification!
You deserve a way more visibility, great content!
Thank you for the kind words! I won't be sad if you can help me share it with more people 😜
Thank you for sharing your knowledge in such an amazing way. I would like to suggest you put all these concepts into practice, implementing it in some language you prefer. I think that would be great.
Thank you for the suggestion! I'm trying to focus more on concepts but maybe in the future I can include some code too 🙂
Great content - enjoying the series so far!
Glad to hear that! :)
Very nice video - thanks for giving me a good understanding!
Thanks! Glad it was useful!
Hey, thanks man for the awesome series..love you ❤
Loved the illustrations. Subscribed immediately
Thanks :)
Perfectly explained! Thanks :)
Anytime!
Brilliant video, great explanation
Thanks! Glad you enjoyed it!
thanks for this video series. What would be nice to see is that if you could explain different architecture Patterns and go for a sample project and select a pattern with explaining reason and implement the architecture with technology and create at the end a very simple product. Let's say a web application built through cloud and could also be implemented by watchers by watching your video. Then another example another pattern implementation. With those key samples, the one who has interest in learning software architecture can build his/her understanding and build his/her own knowledge about software architecture and implementation of it.
Thank you! Glad you enjoyed it!
I've been thinking about it, but also would like to keep the videos short. I can try to come up with an idea.
bro this info is awesome! , THANKS!
Thank you for watching! If you'd like a specific topic don't miss the poll in the community section!
very very nice tutos, Big thx for the effort !!
Thanks!
Great video, thanks a lot! I just wish audio was a little bit clearer. Since I'm not a native english speaker I had trouble understanding some parts. I tend to dislike videos with background music for the name reason.
Bus still amazing. Moving on to the next parts!
Oh I try also to have subtitles in other languages and fix the close captioning to help in that sense, but I'll take the feedback also for new videos.
Thanks!
Nice easy to understand explanation
Thank you! Glad you liked it!
great content, thanks
Thanks! Glad you liked it!
Thanks. Awesome explanation
This is great, thank you so much
Glad it was useful!
Nice explanation
very helpful!! thanks!!
Glad you liked it!
very very usefull
Glad you liked it!
For me its hard to understand these things but one day i will reach to this
What is unclear? Anything I can do to help explaining it better?
really good. feel better than Martin Fowler's!
Thank you very much! But incomparable Martin Fowler is a legend and this video just takes a small part of what he he has talked about EDA. Thank you though! :) Hope you continue enjoying the series
When you say broker, do you mean just a queue (i.e. kafka)? Are there other types of brokers? Maybe a cache?
Basically a broker is a system that is able to pass events (Kafka being an example). It's not only a queue as a broker can have different ways to do so (topics too for example) but it does follow the publish subscribe pattern. Here's a definition: solace.com/what-is-an-event-broker/.
Hope is clearer :)
@@ADevStory thanks!!
Very nice! Thank you for the video!
One recommendation, invest in a microphone to increase sound quality. My ears are bleeding 😂
Yeah newer videos sound better. Sorry about that!
Thank you for the explanation it was really comprehensive! My question is, can a response to an event (order) can also be an event (order/event)?
Yes it can. But keep in mind that if you are expecting a response it would be a request-response model .
If I understand your video correctly, EDA uses events while API's use commands. How does using API's fit in this EDA story? It is something completely different, or can both be combined? (If so, are there brokers able to both: 1) receive events, queue them, make them available to other services, and 2) maintain an inventory of "API locations" and call the respective API and redirect the response back to the original requester.)
So there are different things here.
1) API is Application Programming Interface. It's basically a contract for your app. So Events can be part of the API.
2) I think you meant rest/rpc apis which most are synchronous / command like executions. And that's the main difference with EDA. You can implement some type of EDA via wev by using technology like websockets. In a local machine tou can also implement EDA by having something like NodeJs' Event Loop, it having a process periodically check if there are events for it to process.
The main takeaway here is that in EDA the communication is asynchronous and the coupling is low, so it is indifferent to the underlying technology (can ve Kafka, http, a process, etc). The "calling application" doesn't know anything about the application that will end up executing the task. And the executing application processes it whenever it receives the event.
Hope is clearer :)
In your profile image, Character D and S are swapped. :) Thanks for the video, it was quite helpful.
Glad you liked it and it's great you noticed 😁 the idea is to be the acronym for A Dev' Story 😁
very well sir
This was a great video.. thanks!! One question- you mention that there isn't a single point of failure with EDA. But isn't the broker in your diagram a single point of failure? If that goes down, the rest of the system is also impacted right? The services themselves are up and running but with no events, they will not be processing anything.
Hi! Sorry for taking long to get back to you. This is a good question! Thanks for asking.
So in summary, in any distributed system you face the issue of any component being able to fail (technically in non-distributed systems too, but it would make the whole system fail). There are things that can make the whole systems fail, think for example: the network and electricity. If those go down, so does your system. But network or electricity are typically not considered a single point of failure. There are mechanisms that allow to make it more reliable, even when they can fail (redundancy, partitioning, batteries, etc).
Same thing happens with the broker. A message broker is typically a system that is very efficient and reliable to handle _just_ message passing. It typically is a distributed system with multiple nodes, replication, and reliability considerations that make it highly available. Of course it can happen that it goes down and take all the communication between services too, but typically this risk is highly mitigated.
I found this article from Ciaran O'Donnell that might help clarify it a bit more: ciaranodonnell.dev/posts/message-broker-as-spof/
There's also the Fundamentals of Software Architecture book that has a chapter on EDA where it explains it (amzn.to/3HSKYXC *)
Please let me know if it isn't clear :)
And again, thanks for watching!
* Disclaimer, I _may_ receive some payment from Amazon if you go through this link and buy the book at no additional cost to you.
Thanks for your great sharing. Since i'm very junior and i'm preparing system design for interview, I'm just wondering what doest event-driven play a role in system design or there are two totally difference concepts
In the example where a response comes back to the user after confirming payment, how would you route that response back to the user? Are there any options beyond polling from the frontend or using a web socket (which makes your server stateful)?
Not much else. So basically there are two ways from the client: pull (polling) or have a open connection to receive the message (websockets, SSE, http2 type connections and the like).
You can have ways to notify the client via an intermediate service. Even having a websockets might be fine if you are able to restablish the connection in case of failures.
@@ADevStory makes sense, thanks for the reply!
Any time!
Good job dude
Thanks!
I have a question about the single point of failure part,
Doesn’t the broker then become the single point of failure ?
If it’s down then no event can be sent or received ?
If so, how can we say that this approach solve the problem of having a single point of failure ?
Hi! Sorry for taking so long to reply, this is a good question, I already answered it in another comment but RUclips doesn't allow me to link it, so I copy here the same answer :D
So in summary, in any distributed system you face the issue of any component being able to fail (technically in non-distributed systems too, but it would make the whole system fail). There are things that can make the whole systems fail, think for example: the network and electricity. If those go down, so does your system. But network or electricity are typically not considered a single point of failure. There are mechanisms that allow to make it more reliable, even when they can fail (redundancy, partitioning, batteries, etc).
Same thing happens with the broker. A message broker is typically a system that is very efficient and reliable to handle just message passing. It typically is a distributed system with multiple nodes, replication, and reliability considerations that make it highly available. Of course it can happen that it goes down and take all the communication between services too, but typically this risk is highly mitigated.
I found this article from Ciaran O'Donnell that might help clarify it a bit more: ciaranodonnell.dev/posts/message-broker-as-spof/
There's also the Fundamentals of Software Architecture book that has a chapter on EDA where it explains it (amzn.to/3HSKYXC *)
Please let me know if it isn't clear :)
And again, thanks for watching!
* Disclaimer, I may receive some payment from Amazon if you go through this link and buy the book at no additional cost to you.
For a request that expects a response in an event-driven architecture, how would you send back the response? What are the common ways to do this?
You can send the response as another event that the first service expects / is subscribe to
xyc c c c c, , y a ys foon te ny
@ComputerWhisperer, why may I choose Event-Driven Architecture instead of Layered Architecture, which both scalable and, as I see, Layered Architecture provides even better performance?
Depending on the use cases sometimes event driven can be more scalable and have better throughput. For example, in bidding systems, online multiplayer games or even Twitter or feed-like systems. The type and amount of data is better processed in an event driven model there.
There are some other cases that are less intuitive at first like web servers based on Netty or NodeJs where an async / event driven model takes advantage of the very slow processing of input/output of a connection.
Hope it's s bit clearer if it's not I can explain more.
Just as a final thought: layered and event driven are not opposed. You can have layered AND event driven systems (for example, web frameworks).
Can u explain the performance drawback on choosing event driven architecture
Great question! The answer could be really long and become more of a discussion but will try to be concise.
When you use distributed systems there's always a hit in performance compared to doing the same job in a single machine. Same happens for example in a machine with single thread/single process vs multiple processes. There's an overhead of: having to deploy more resources, greater latency in network communication (vs in memory) and serialization/deserialization among other things. Of course distributed systems can help improve a system's overall performance in other ways: having load balancing and parallelizing tasks, as well as other capabilities like (potentially) better maintainability, and more robustness. But if you could have a big machine that never goes down and it's able to parallelize jobs, it will more certainly be more performant than a distributed system.
Add to that that in event driven architectures you need a message/event broker system in the middle between every system. So any communication between a Service A and a Service B has to go to an intermediate Service C which is a broker. As fast as the broker can be it adds some overhead and it will take a hit on performance. There are things to handle like: how to make sure events are not written/read twice? what happens if the broker goes down? and many of these decisions add to the overall performance.
Is this something important? Should you discard EDA completely or use it always? It depends a lot on the context. It could be that scalability is more important in your system than performance for example in which case EDA tends to be a good option, or it could be the other way: maybe your system just need to respond within a very tight bound of ms and you're actually not planning to scale much. So at the end it depends a lot on the needs of your project.
Could you help me explain more about 2 points in details: the benefits of "loosely coupling" and "dependency inversion" (some examples in real life about the difficulties if we don't use EDA and how EDA solves in these examples) when we use EDA?
For example (Service A Service B C D directly) vs (Service A message broker Service B C D):
- If I use a message broker, Service A won't have to care what Service B (or C D) is, Service A just needs to send an event, and Service B, C, D just need to receive, but I still have to configure the message broker so that it can be aware of the services if we have to change the endpoints.
- If the customers ask for requirement changes (input or output changes), there will be a high chance that all services related to the functionality (service A, B, C, D in this example) will have to change
- If one service is down (because of failure or deployment time), the others still can be online, but the overall functionality won't work properly, because one service requires all other services to work in order to achieve the goal
These are the questions that I've been having a headache for a long time... Could you help me clarify and suggest me some best resources related to this field (microservices, distributed system, event-driven architecture, DDD).
I wish you the best Christian.
1. You only have to configure the message broker yes, after that you can just plug services into that broker, and as long as all services correctly implements the Events (as in a contract) they are ready to go
2. You always have to change software if you get new requirements, loose coupling doesnt change that, but it can make it easier. You can take down Service A and substitute it with a new service without changing anything else in your overall system / architechture, as long as the new service has properly implemented the required Events (contracts)
3. Correct, if all your use cases needs all services to be online, then your system wont work. But in best case scenario, some use cases will still work, despite one service being down. It is at this point you might load balance and have multiple instances of the same service running, to counteract system failures due to just one service instance going down. Rememeber, EDA coupled with microservices makes your system insanely scalable and resiliant.
Some implementation rs required. Architects deem to be complacent about not going full length, conveniently avoiding some details
@A Dev' Story, what's the solution, if a producer like web needs a response ?
It depends. If you are waiting for a response typically event driven architecture is not the best approach. EDA works best for asynchronous communication (when you don't expect an answer). In the case of waiting for an answer you are looking for synchronous communication or request/reply patterns.
Of course you can implement it also with EDA but you have to deal with more complexity. So in the case of web requiring an answer my suggestion would be not to use EDA or change the behavior on the web to be async.
What is eventConsumerBufferSize? There is a use of this in circuitbreaker design pattern but it is not clear what this does
Where did you get that from? Is it a specific config?
does it EDA have the similarity concept with mesh architecture ?
What do you mean by mesh architecture? Do you mean service mesh?
I like this video and its good but on some places your explanation is very fast and its hard to understand. Kindly slow down the explanation way which will help us to understand clearly. Thanks for this video.
Thanks for the feedback! Will try to do in future videos!
Can you do a video about message driven architecture? It's use case?
Event driven and message driven are very similar. I can think of doing a video but won't be soon due to time limitations 😅 what doubts did you have?
Cracking content, but please drop the background music!
Glad you liked the content. Why didn't you like the background music? 😅
@@ADevStory, all background music is distracting! 😢
Oh sad to hear that. I found out actually the opposite. If you want to try, my first videos (algorithms) didn't have any and it was harder to focus I'd say (same for other videos online). I can try lowering a bit more the background music though so it's less distracting. Or maybe having some parts of the video without it. Do you think that'll help?
This sounds like the Observer/Observable pattern
It's related. I mean partially as you implement observer/observable pattern with an event driven architecture. But you also implement other patterns like event sourcing with it.
İs event driven also know as event centered ?
I've never heard of event centered. What do you mean by that?
and what is the full form of BE on layered architecture that u had drawn?
What do you mean?
Is there a git link to check sample projects on these architectures please ?
I haven't created it but if it's helpful I can look for some time to do it 😁
consistency part is little not clear , as when you want to have something like happens before relationship , you might want to use chain of events. and now your system it consistent.
If I get the question right, I meant eventually consistent. So when you do a transaction or request/reply all systems are seeing the same information after the operation was executed. With event driven a system sends an event and the other system will read it at one point in the future. If multiple systems are reading the event they may do so at different times
Hey, your audio is way to quiet - i had to turn my speakers all the way up to 100% to hear your voice. Please consider turning the master volume up next time while mastering your videos (its easier to turn the volume down a little rather then having to turn the speakers up to 100% and having to adjust volume for all other running applications)
Thanks! May I ask you on which device are you listening it? Some people have reported it but I've tested in many devices (android phones, tv and desktop) and everything seems to fine. In my latest videos I've been increasing a bit more the volume just in case
Consider a microphone, the room reverb is bad
Thanks for the feedback! I'm using one but probably will need a different one. 😓
link for next part of event driven architecture
It hasn't been released yet but soon :)
Good video but too low volume.
Thanks . It improved in the next one in the series
The meaning of your logo ?
Just a QWERTY keyboard with the keys inverted (ADS instead of ASD)
the volume is very low, you can hardly hear it!
Sad to hear that. Will try to improve next time
he is looking like andrew TECH (tate)
If you are like me and followed the playlist from the beginning, you might get confused about Layered architecture and how did event driven architecture come into the picture. Here is a link that I found helpful: www.ibm.com/cloud/blog/four-architecture-choices-for-application-development
Oh this is a great article. Thanks for sharing! Sorry it was a bit confusing. It's actually 2 series of videos and are related but not continuos though.
But the article you shared connects them nicely!