How to do Distributed Transactions the RIGHT way? Microservices

Learning system design is not a one time task. It requires regular effort and consistent curiosity to build large scale systems. Moreover, every system has different requirements and meeting them requires expertise and people with varied and specific knowledge. There are a lot of resources to learn through videos. But not everyone enjoys that mode of learning. Instead some people understand things better by reading and thinking on the points put forward by the author. Such people can access these in different ways - blogs, articles and books. We have come up with this video to put light on one such aspect, that is - how microservices communicate using events.
------------------------------------------------------------------
Relevant Links discussed in the video:
------------------------------------------------------------------
Book - www.thoughtworks.com/insights...
------------------------------------------------------------------
Recommendations
------------------------------------------------------------------
Our full courses on youtube:
✒ System Design Primer Course: • System Design Primer C...
✒ REST APIs made easy: • REST APIs MADE EASY
Some paid courses that we recommend:
✒Educative.io: bit.ly/3qnW5ku
✒Interviewready.io: get.interviewready.io/ (Use coupon code SUDOCODE for extra discount)
------------------------------------------------------------------
About Us
------------------------------------------------------------------
Created and Instructed by:
Yogita Sharma
✒ LinkedIn - / yogita-sharma-83400b55
✒ Instagram - / sudo.code1
✒ Facebook - / sudo.code
✒ Medium - / yogita088
Post-production(editing, thumbnail etc) managed by:
CiKi
✒ Website: www.ciki.co.in
✒ LinkedIn: / 74735937
Colors and design by:
Naini Todi
✒ LinkedIn - / nainitodi
Both Arpit and Yogita are software engineers and want to help other software engineers become better by providing high quality and well researched content by adding their creativity and teaching twist.
------------------------------------------------------------------
Join Us
------------------------------------------------------------------
Hangout with sudoCode:
✒Discord Server: / discord
For business:
✒Email: [e-mail]
-----------------------------------------------------------------------------------------------------------------------------

[@premraj.m]

excellent, this is the perfect way to teach, 13 went off very fast for me while watching this video

[@xellos5262]

Concise, simple visuals, clean and non-monotone speech, in short fabulous. Thank you for the video, rare to get a good overview in such short time!

[@mhopado]

Thanks for explaining such complicated topics in simple way. In real world you, will find the hybrid approach, where a orchestrator service keep track of the state of the transaction while passing the events from one service to other. So in case of failure, the orchestrator will retry from the failure state of the transaction or revert back the previous operation.

[@qichengri5517]

COOL! Then your messaging/queuing system doesn't need to be as reliable.

[@evoxtorm]

We can also use Try-Confirm/Cancel approach also but we have to take care of out-of-order execution. But yes Saga are preferred due to their liner order of execution

[@rakeshkhuntia2093]

Thank you so much, Its very simple and clear explanation.

[@sreejeshraj4800]

Thank you very much for your videos - excellent content, to the point. I have a request - can you please do a video comparing the similarities / differences between various styles of programming - messaging, event driven, asynchronous, reactive etc. I know that you have done vides on messaging, pub sub etc. - but a comparison video will make these concepts clear rather than doing separate videos for each topic.

[@ammabalasimha]

Explanation is very clear. Thanks a lot

[@duffy9090]

Great video, thank you for putting these topics together

[@AK-vx4dy]

Very clear explanation of realy complicated things

[@warriorfb2010]

Excellent. I look forward to watching your other videos. Thank you!

[@mohammedhuzaifa8654]

thanks dd for putting it in a way that is easy to understand

[@rajchaurasiya1265]

Thank you mam for this valuable content 🙏

[@BitsAndBytes0101]

You explained it very well. Thank a lot

[@ashishjaiswal1090]

Nice explanation through animated slides seems do a lot of work thanks for explaining in intersting way, is there any source/link using java it will be helpful.

[@blasttrash]

nice video. but one question at 6:58, while doing backward recovery, what if one of the backward step also fails? 😅Then state of our system is stuck as we cant move forward nor can we move backward.

[@ashishmaurya3669]

That's why it preferred async communication between microservice so request doesn't lose the track. Also if we go for sync we need to implement failover mechanism for eg retry the request to certain number.

[@Vaibhavatutube]

Brilliant explanation and presentation. Thanks!

[@phillipdino]

Such a grea video. Thank you for the explanation.

[@sachinshukla1095]

Beautiful explanation....❤

[@shashavalijava9]

I 💕💕💕 your explanation . thanks you

[@f135ta]

Avoid distributed transactions at ALL costs in microservices - just use events and eventual consistency. This approach causes so many headaches I can't even list them all here

What if I need strong consistency?

[@jeevan19876]

Sagas are eventually consistent though they are distributed transactions. The events from one service to another are usually asynchronous. Two phase commit is used to achieve strong consistency snd should be avoided

[@f135ta]

@@jeevan19876 - SAGA's are a serious complication that you need to be 100% sure you need before applying.. There are far simpler patterns that solve the problems just fine IMO

[@nagareddy9744]

thank you

[@ravitejaakkala6114]

well explained !!

[@soni.himansh]

Great video

[@Md_sadiq_Md]

Pushing the algorithm ❤️

[@kotojava]

how to sort issues when some process just can't have compensations? eg we send money or we send email with some good eg ebook. So these actions can't be undone.

[@jeevan19876]

There is a pivot point in transactions, if any failure occurs after pivot the services would retry the steps and run for completion Else if pivot is failed just rollback transactions before pivot

[@kotojava]

@@jeevan19876 some actions might not be rollbacked.

[@AkshayMukadam]

live demo would have been great i.e hands on would have been good

[@tendaikawadza4492]

how do i add user details to each service

[@jeevan19876]

Your service would be communicating with user service to get details based on id Each kafka event would contain a userid

[@bhaskarsadawarte7696]

🙌

[@jeevan19876]

I am in disagreement with that we need to avoid distributed transactions, distributed transactions are very common in microservices and sagas are used most of the time to ensure eventual consistency.

[@chessmaster856]

There are more and more failue points. You just keep doing lot more work keep lot of logs. Try again and just do too much work. It us easier to talk and go into architecture and blame developers failures in implementation.. there are too many failure scenarios possible.the best you can do is have robust hardware that wo t fail and kee forensic record or log of every step before doing and be able to go back and analyze retry. All this is easier in chat sites and more risky in financial world. You Tube can easily say that your count may nit be accurate on so and so date. That is fine. That is not possible in financial transavtions

[@chessmaster856]

Most architects have never implemented this in real life and would avoid going near development

[@chessmaster856]

But this video highlights most of issues in distributed transaction correctly

[@s.sambit1676]

Mam, You start looking old😔 but ur explanation growing sharply.

[@sudocode]

Well dear ignorant youngster you should probably know that I am older than I look and younger than I feel. Sad that’s the most interesting thing you observed about me 😅

[@theunusual4566]

What a shit comment on the Excellent video. Mam you are amazing as always.

[@warriorfb2010]

And you're immature and likely not worthy of working within a professional business domain.

[@CommonSense-person]

​@@sudocode kya thoka usko wah