โพรโทคอลยืนยันแบบสองระยะ

When one business action spans two databases, you want all-or-nothing: both commit or both roll back. A single local transaction cannot span separate systems, so we need a coordination protocol.

Two-phase commit (2PC) is a classic protocol where a coordinator drives multiple participants to a unanimous decision: commit or abort.

The coordinator asks every participant: can you commit? Each does the work, locks the resources, writes to its log, and replies yes (prepared) or no.

If all said yes, the coordinator tells everyone to commit. If anyone said no, it tells everyone to abort. The decision is final and recorded.

2PC provides atomicity across participants: there is no state where one committed and another aborted, as long as the protocol completes.

Here is the fatal flaw: if the coordinator crashes after phase 1, participants are stuck holding locks, unable to decide. They block indefinitely until the coordinator recovers.

Resources stay locked for the whole protocol round-trip. Across services and networks this dramatically reduces concurrency and availability, which is unacceptable for high-scale microservices.

2PC favors consistency over availability. A network partition during commit can freeze the whole transaction, violating the availability that distributed systems usually prioritize.

The XA standard implements 2PC across resource managers (databases, JMS brokers). It works, but it tightly couples services and inherits all of 2PC's blocking issues.

Microservices prize loose coupling and availability. They generally reject 2PC in favor of the saga pattern: a sequence of local transactions with compensating actions, accepting eventual consistency instead of distributed locks.

2PC is not always wrong. Within a single trust boundary, low-volume, short transactions over reliable infrastructure (e.g. one DB plus one message broker) can use it safely.

Test your 2PC understanding.

You learned 2PC:

• 2PC coordinates an all-or-nothing commit across participants
• Phase 1 prepares (locks and votes); phase 2 commits or aborts
• It guarantees atomicity but blocks on coordinator failure
• Locks and the CAP trade-off hurt availability at scale
• Microservices prefer sagas; 2PC suits small, reliable, single-boundary cases