Introduction to Two-Phase Commit (2PC)

Two-phase commit (2PC) is a distributed consensus algorithm that was historically developed in the context of database transactions. A transaction is an abstraction that usually provides the ACIDA=Atomicity, C=Application's notion of Consistency, I=Isolation between any concurrent transactions, and D=Durability of the committed transaction data. correctness guarantees to the end programmers. The “A” in ACID refers to atomicity—a transaction either commits in total or aborts; in other words, something happens completely or it doesn’t occur at all. When we want different systems to either commit or abort together, we use the 2PC algorithm. In the context of transactions, the consensus is about the binary decision of either committing or aborting among all the participants in the 2PC protocol.

A common use case for 2PC is when a transaction reads and writes multiple database shards, and an application wants to ensure that all such changes happen as one unit. In this case, consensus means that every participant should be on the same page. The 2PC algorithm can be used in any scenario that requires atomicity across all participants.

In real-life scenarios, we know that achieving consensus can be challenging, even for simple decisions like choosing a restaurant among friends. Because the 2PC needs to bring all the participants on the same page (we can't just take the majority), failures such as node or network failures pose significant challenges to the 2PC algorithm.

This chapter will elaborate on transactions a bit more before discussing the 2PC algorithm. We'll then see how different failures, like network and node failures, are managed by the 2PC algorithm.

Transactions and atomic commit

In a distributed system, transactions are used to manage the reading and writing of data among nodes. A transaction is a unit of work that reads and writes data from one or more nodes. Achieving atomic commit is essential to maintain consistency and reliability, meaning that all transaction changes are committed, or none of them are. However, ensuring atomic commit is challenging in a distributed system because it requires coordination among multiple nodes.

For example, consider a banking application that transfers funds between accounts. The transaction involves deducting the amount from the sender's account and adding it to the receiver's account. To ensure atomic commit, the transaction must be coordinated across multiple nodes to ensure that the debit and credit operations occur atomically. The withdrawal and deposit both happen, or they both should not happen at all. (In the context of ACID, the “C” refers to the application's notion of consistency. In our example, the invariant is that across all accounts, the credit and debit amounts should always be equal. Atomicity helps the application achieve and keep its consistent state.)