2PC : Inside the World of Distributed Transactions

The 2PC protocol is typically used to coordinate transactions across multiple services or participants in a distributed system. The protocol involves a centralized coordinator and multiple participants, each of which is responsible for some aspect of the transaction.

https://developers.redhat.com/blog/2018/10/01/patterns-for-distributed-transactions-within-a-microservices-architecture

The protocol works as follows:

1. The coordinator initiates the transaction and sends a “prepare” message to all participants, asking them to perform any necessary operations and prepare to commit the transaction.
2. Each participant executes its part of the transaction and responds to the coordinator with either a “yes” vote (indicating that it is ready to commit) or a “no” vote (indicating that it is unable to commit).
3. If all participants vote “yes”, the coordinator sends a “commit” message to all participants, instructing them to finalize the transaction.
4. Each participant executes the “commit” operation and responds to the coordinator with an acknowledgement.
5. If any participant responds with a “no” vote or fails to respond, the coordinator sends an “abort” message to all participants, instructing them to roll back the transaction.
6. Each participant executes the “rollback” operation and responds to the coordinator with an acknowledgement.
7. Once all participants have acknowledged the commit or rollback operation, the coordinator sends a final response to the original transaction initiator indicating the success or failure of the transaction.

This protocol ensures that all participants commit or roll back the transaction in a coordinated, consistent manner.

Drawbacks:

The protocol can be slow, resource-intensive, and inflexible, and it can lead to blocking and deadlocks in certain situations. As a result, alternative approaches, such as the Saga pattern, are often used in modern distributed systems. Some drawbacks of 2PC are:

1. Slow and resource-intensive: The 2PC protocol can be slow and resource-intensive, especially in large-scale or high-traffic systems. The protocol requires multiple round-trips between the coordinator and participants, which can add significant latency and overhead to the transaction. Additionally, the protocol is not well-suited to handling large numbers of participants, as each participant must be contacted and coordinated individually.
2. Blocking and Deadlocks: The 2PC protocol is a blocking protocol, which means that a failure or delay at any point in the transaction can cause the entire system to block or deadlock.
3. Single Point of Failure: The 2PC protocol relies on a centralized coordinator to manage the transaction. If the coordinator fails or becomes unavailable, the entire transaction can fail or become stuck, and recovery can be challenging or impossible.
4. Complex: The protocol requires careful coordination and error handling, and participants must be designed to handle both the forward and backward recovery processes.