Implementing Distributed Transactions using Two Phase Commit Protocol

Build Your Own Redis / DNS / BitTorrent / SQLite - with CodeCrafters.

In the previous video, I explained the theoretical aspects of a distributed transaction using a two-phase commit protocol. In this video, I implemented the protocol locally using Zometro's 10-minute food delivery scenario. I detailed the components needed, database schema understanding, and how the two-phase commit protocol ensures atomicity. By splitting the process into preparation and commitment phases, we achieved atomic transactions. The key focus was on user experience and avoiding resource contention in a distributed setup. The architecture involved order, store, and delivery services communicating to ensure seamless transactional experiences.

# Recommended videos and playlists

If you liked this video, you will find the following videos and playlists helpful

# Things you will find amusing

# Other socials

I keep writing and sharing my practical experience and learnings every day, so if you resonate then follow along. I keep it no fluff.

Thank you for watching and supporting! it means a ton.

I am on a mission to bring out the best engineering stories from around the world and make you all fall in
love with engineering. If you resonate with this then follow along, I always keep it no-fluff.

[kunalchhatwani]

This channel is a gold mine, appreciate the efforts you put in.👏

[dasmala]

Your videos have so much information and to the point details in them, I am lucky that youtube has recommended me your videos

[udaysolanki]

Awesome Video
Just to understand payment flow too.
what should be the order for payment here
1. Reserve -> Payment-(if payment fails then remove reservation, exit)> Assign (if assign fails then refund)
2. Success Payment->Reserve(if reserve fails then refund, exit) -> Assign (if assign fails then refund)

[VimalKumar-rdol]

Great video, keep adding more videos !

[venkatajagannath]

Thanks a lot for this video, would really love to understand working of @Timer and the nuances of implementing the same. Can you explain that ?

[moshoaib]

You channel has an addiction. Amazing content, loved it ❤️

[xenky]

Good example, nice explanation, thank you.

[srawat]

@AsliEngineering - what if in the placeOrder() we are able to make 3 api calls but the app instance crashes down before we book the agent for the order? I guess this case is not going to be handled.

[shikharsubedi]

thank you for the code demonstration. it really solidified the understanding. I really need to learn go.

[gurupreetsingh]

Thanks nice explaination but how we can implement timer thing..

[SwikarP]

Thanks awesome! This is high quality explanation.

[vpk]

Good video. Looking forward for implementation of Paxos and Raft as well.

[renbangbprd]

Where is the link to the previous video? I can't seem to find it

[tusharabbott]

Great video loved it. btw which vs code theme your are using?

[architshukla]

Very Informative channel and content . Keep it Up !! 👏👏👏

[NidhiSinghPersonal]

This video got me subscribed to your channel, Amazing content. Loved the implementation bit :)

[kaal_bhairav_]

12:45 order service is acting as an orchestrator [* link: orchestration vs choreography]

[shibasispatel]

Could you please explain why did you use Select for update and then update it? I know it will lock that row in a write exclusive lock so that no other transaction can update that row. But what would happen if we directly update that row by using "update agents set is_reserved=true and order_id=1 where is_reserved = false and order_id = null"?

[agauniyal]

I'm having difficulty understanding, how is the code representing distributed transactions?If I take it on literal face-value, there are no 2 different datasources so current scenario could have been done under same transaction, why going through the pain of taking locks and everything? Distributed transactions are hard because there are 2 or more services/datasources etc which don't share any transaction id/object/etc. This example doesn't fits the scenario.
Please correct where I'm wrong. Thanks.

[GauravSharma-wbse]

we can make transaction in only commit phase itself....if both commit phases goes fine then accept order or else throw unacceptable error...…isn't it?