When one business action updates several databases, the dangerous case is partial success. One database commits, another rolls back, and the user is left with a broken result. Two-Phase Commit (2PC) is the classic protocol for avoiding that. It answers one focused question: can several systems all commit, or all abort, the same transaction?

The idea is simple. One node acts as the coordinator. It asks every participant, "Are you ready to commit?" If everyone says yes, the coordinator tells everyone to commit. If anyone says no, or does not answer in time, the coordinator tells everyone to abort.

2PC is still important. Many distributed databases and transaction managers use some form of it. But it works best in a controlled environment: short transactions, reliable participants, durable logs, and a coordinator whose decision can be recovered after a crash. It is usually a poor fit for slow service workflows, external APIs, and long-running business processes.

This chapter explains how 2PC works, why it blocks, and when you should avoid it.