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

Problem

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.

• Prepare
• 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.

Working

• All or nothing: It is all or nothing. All services complete the transaction, or we roll back the partial ones. Failures are handled through rollbacks.
• Latency: Since the coordinator awaits responses from all the participant services, the longest response time determines the overall response time of the system.
• Single point of failure: Improper implementation of the coordinator would turn it into a single point of failure for the system. Sufficient redundancy should be built at the service level to avoid deadlocks. Also, each coordinator should have redo logs to resume working in case of crashes.

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