Definitely one of the better high level overview presentations I've seen on these subject matters. Conceptually I was already familiar with the architecture and I have even put some into practice by rolling our own custom Event Store based on the Event Sourcing architectural pattern (though I admit, probably very poorly) but the speaker has done a great job of combining all of the knowledge and approaches that are our there. Best 40 minutes I've spend on deepening my knowledge and understanding in this area. Thanks for the upload.
Most definitely one of the most complete walkthrough of SAGA implementation using event sourcing (and orchestration). Excellent job on combining approaches, patterns, and examples out there.
brilliant talk , how all the concepts around micro services and event driven arch came together was like an art masterpiece . thank you for posting this talk . Appreciate it .
A common argument for microservices is that it leads to decoupling between parts and less ”spagetti”. However I fear that overusing publish/subscribe yields the same kind of spagetti, just over a network instead of between functions and classes.
That was really slick. Thx a ton. I am shocked by the existing gap between what the industry has and what most of people in Academia are trying to re-invent. IoT Researchers should have the topics in this talk as their starting point and improve up-on. Not re-invent the same wheel 1000 times.
Good one, indeed. Inclusion of real production problem solution using patterns like Not only DB, Sagas, Event sourcing helps to understand real-life problem along with the solution.
At CQRS slide (36:24 minute) why not use some replication feature from database instead of event backbone ? Not clear for me the benefit using event backbone on this case.
They do not solve the same problem. Event sourcing can give eventually consistency with auditable events while the saga pattern tries to solve the issue of having distributed transactions.
Show some code. Everything looks good at high level. Someone will do something and everything is good like drawing a car on paper and say that everything runs with no problem. That is not enough
There's alot I don't agree with. Purely from a user experience point of view. Why would you pay for something then get a push notification that it was successful? You are sacrificing HCI concepts for? Request response matches how humans interface with software. You click on something then it tells you what happened.
Doesn't have to be a push notification for it to be asynchronous. You could have the same event driven architecture he describes but the user gets the update by polling from the front-end like most reactive web apps. The example he gave doesn't have to change user experience. You typically get quick response times when you interact with sites like youtube and instagram yet they are using this event driven architecture in the backend..
@@joek4563 Don't get me wrong. I am not talking about all of EDA. I use EDA in our systems at work but when it comes to HCI we fake responses and use a concept of eventual consistency. We work with a philosophy that is to tell the user immediately if something "should" succeed. The user can go about their business while the EDA is still processing the payment or what not. Only in extreme cases such as system failures will there be a chance of the event not being processed. I am talking specifically about his example, I don't agree with using push notifications to tell the user if something is complete. Push notifications are reserved for notifying the user about something that was not initiated but the current user but rather some external source.
@@mandarin8513 I am intrigued, Mitch. We use Push Notif. for notifying the user about a call or that a doctor is available. In what context do you think PN are not good, why? and if you wouldn't use it in this case, what would you rather use to let the user know his payment is successful?
@@TrulyLordOfNothing I'm not saying that PNs are not good. They are just not good in this context. For example you said to know when doctors are available or when you receive a phone call. Both of those events are initiated by an external source and not by you. This is a perfect case for PN. When you initiate the event such as paying for something, then why should a user wait for a PN just because you are using event based architecture. It means you sacrifice UX for the sake of simple backend architecture when there are more complex solutions such as eventual consistency and saga patterns. You can tell the user immediate the payment is successful on the response of the users request.
This is some "straight jacket over Kafka" presentation. I think there is a lot of confusion in it over terms, the definitions are not specific enough, there is a bit of hand waving. I'm not sure the presenter knows what write algorithms look like and what happens in the event of failure. The pros and cons are not explained. Pipes should be dumb and services smart. Where is DDD?
