such a well explained video. only after watching this have i understood the difference between microservice and event driven architecture. extremely clear explanations. thanks for the video
One thing not well explained in the video is that we should keep in mind that events are sent after the work is done. Or for long running process you can have an event saying processing and another one done (but even here you would probably use a queue). But in most of cases events mean something changed, the subcriber is not the one doing the work, it is doing extra work afterwards. You want the subscriber to read consistent data. (ex. a database)
Hi buddy! Thank you for this. What about the data storage, where does that go? So mobile number change event is captured but what where is the mobile number history kept? I.e. at point 1 it was 1234 and was updated to 2345 and so someone can report on the history of the mobile number?
Hi Karthik, Very well explained. Event driven architecture results in "Eventual consistency", so automating at API level becomes challenging at times. So far I used retry to overcome these flaky tests. Any suggestions from your side Karthik.
Hi Sharath, The best way to test the application is to test from the consumer of the event rather than the producer itself. Producer testing will make once again the classical thinking of testing the non-event driven APIs, other way will solve the problem Thanks,
Hey great video, quick question though. If the app/UI is always listening for events to be published, would that also mean that it will have to maintain a open websocket connection with the api? If so, wont this architecture require a open stateful connection for every connected client? Thinking of the increased infrastructure costs with this architecture, if any. Thanks
Yes, and these connections can be stored in a service that maps the customer id to the web socket session, using the event bus to initiate messages back to the client via web sockets. Everything is abstracts into these event reactive services so everything can scale, but not for maximum efficiency or even speed.
Hello Karthik, good video. I hope you are well in level 4. I have built a test strategy on a few micro-service orgs now and I am curious what your take is (given the example in this video).
Hi Mate, Yes L4 is hard, but keeping safe so far ! Hope you are doing safe too. Actually, I am planning to create an application on EDA using .NET and also wanted to explain how to test the same. This way, it will be even more better to understand. But to your question, the best way to test is to test the consumer rather the producer itself.
@@ExecuteAutomation is this a Queue? consumer polling from head or tail. if an event on head or tail, not consumed, the events behind will have to wait until the one on the top to be consumed?
@@AmNotLegend yes, but it’s event streaming queue using Kafka or RabbitMQ. It’s not like stuck there until someone consume, if so, there is no point in having this used by multiple services
such a well explained video. only after watching this have i understood the difference between microservice and event driven architecture. extremely clear explanations. thanks for the video
You speak really well. Thanks for the video.
One thing not well explained in the video is that we should keep in mind that events are sent after the work is done. Or for long running process you can have an event saying processing and another one done (but even here you would probably use a queue). But in most of cases events mean something changed, the subcriber is not the one doing the work, it is doing extra work afterwards. You want the subscriber to read consistent data. (ex. a database)
You explain concepts really well
Nice, clear and simple explanation. Well done.
DJ Karthik on air! Starting from 06:43 😃👍🏻
Nice one thx. Straight to the point.
Thank you! It was a great explanation I learned a lot from this😁
Great video, thanks for the good explanation!
Great video😊
Clarifies lot of high level things, thanks
Really great video! Thanks bro
Thanks for the video
You did a great job explaining, thank you!
Thank you for a great explaination.
Hi...Well explained....Which tool did you used to create arch diagrams?
Let's always do alot of good ❤️
Great video
Very well explained
Thank you sir, very well explanation.. can you tell me which extension are you using in VS code?
Thank you!
Thank you very much for another great video, Karthik
Does memory has any impact while the event is sitting on the topic of the kafka forever ?
Awesome
Very well explained
👍🏻
Is the tell/get pattern also known as the pub/sub pattern? Or are they different?
Hi buddy! Thank you for this. What about the data storage, where does that go? So mobile number change event is captured but what where is the mobile number history kept? I.e. at point 1 it was 1234 and was updated to 2345 and so someone can report on the history of the mobile number?
It’s all going to be stored in your service DB with before and after event in topic(both old and new number)
Hi Karthik, Very well explained. Event driven architecture results in "Eventual consistency", so automating at API level becomes challenging at times. So far I used retry to overcome these flaky tests. Any suggestions from your side Karthik.
Hi Sharath,
The best way to test the application is to test from the consumer of the event rather than the producer itself. Producer testing will make once again the classical thinking of testing the non-event driven APIs, other way will solve the problem
Thanks,
Hey great video, quick question though. If the app/UI is always listening for events to be published, would that also mean that it will have to maintain a open websocket connection with the api? If so, wont this architecture require a open stateful connection for every connected client? Thinking of the increased infrastructure costs with this architecture, if any. Thanks
Yes, and these connections can be stored in a service that maps the customer id to the web socket session, using the event bus to initiate messages back to the client via web sockets. Everything is abstracts into these event reactive services so everything can scale, but not for maximum efficiency or even speed.
Hello Karthik, good video. I hope you are well in level 4. I have built a test strategy on a few micro-service orgs now and I am curious what your take is (given the example in this video).
Hi Mate, Yes L4 is hard, but keeping safe so far ! Hope you are doing safe too.
Actually, I am planning to create an application on EDA using .NET and also wanted to explain how to test the same. This way, it will be even more better to understand.
But to your question, the best way to test is to test the consumer rather the producer itself.
wonderful explanation
if an event not interested by any services, what happens? does it block other events in theQ to be handled by the consumer?
Not at all, it will just sit there and expires
@@ExecuteAutomation is this a Queue? consumer polling from head or tail. if an event on head or tail, not consumed, the events behind will have to wait until the one on the top to be consumed?
@@AmNotLegend yes, but it’s event streaming queue using Kafka or RabbitMQ. It’s not like stuck there until someone consume, if so, there is no point in having this used by multiple services
wouldn't the producer going down be a single point of failure?
Is like putting a program that you didn't design as the heart of your app
great explanation