Week 44: Understanding Two Phase Commit

I was reading about Two Phase Commit, a distributed systems pattern for atomically storing transactions on multiple cluster nodes.


Ensuring atomic property in a transaction is relatively easy when the transaction happens within one application transacting with a single database. However, it would be challenging if the transaction spans multiple microservices or uses heterogeneous database mixes(RDBMS + NoSQL).

Two Phase Commit

This pattern involves a coordinator orchestrating the transaction between the participating microservices. As the name suggests, it involves two phases.

two phase commit Two Phase Commit

Prepare phase: We acquire the lock on the resource we want to update and make the change but wait to commit. If the microservices could do that, it would respond OK to the coordinator in the happy path. It will still respond if it cannot do, stating that it couldn't acquire the resources. After sending back the response, the services await further instruction from the coordinator.

Commit phase: If the coordinator receives a guarantee from all the participating microservices, it proceeds to the commit phase. Else, it aborts the transaction. Timeouts must be implemented at each service level to free up resource locks If the coordinator doesn't send the commit instructions.


Source code for generating diagram via mermaid.js is at https://gist.github.com/sridharrajs/f97ba3ed8c176aeb2b10b5986b21d931

For my new posts, Subscribe via weekly RSS, common RSS or Subscribe via Email