two_phase_commit introduces risk split

two phase commitIntroduces Risksplit brain

Source: Pattern·Target: Failure Mode

Summary

Two-phase commit's coordinator is a single point of failure. If the coordinator crashes after sending the prepare phase but before completing the commit phase, participants are left in an uncertain state: some may have committed and some not, creating a split-brain condition that requires manual operator intervention.

Evidence

·{'The blocking problem': 'if coordinator crashes during commit phase, participants are blocked indefinitely waiting for a decision'}
·PostgreSQL prepared transactions (PREPARE TRANSACTION) can remain in uncertain state indefinitely if coordinator dies
·MySQL NDB Cluster documented coordinator failure as a primary operational concern in 2PC deployments
·Two-phase commit requires all participants to be online during commit: a partition causes indefinite blocking
·Three-phase commit (3PC) was designed to address this but is rarely used due to complexity

Operational Context

·Monitor pg_prepared_xacts for long-running prepared transactions: they indicate a coordinator failure
·Set a resolution timeout: automatically roll back prepared transactions older than N minutes
·Use saga pattern or outbox pattern as an alternative: they avoid 2PC entirely

Tradeoffs

·2PC is blocking: if any participant cannot respond, the entire transaction is blocked indefinitely
·Locks held during 2PC are held across the network: lock duration includes network latency
·The coordinator is a scalability bottleneck: all distributed writes serialize through it

Evidence grounding

Grounded, 5 supporting items

2PC split-brain vulnerability is formally proven (the blocking problem) and extensively documented in distributed systems literature (Gray, Lamport). Production incidents from 2PC coordinator failures are well-documented.