El Three-Phase Commit (3PC) es un protocolo de consenso distribuido diseñado para lograr atomicidad en transacciones que involucran múltiples nodos, mejorando la resiliencia del Two-Phase Commit (2PC) frente a fallos del coordinador. A diferencia de 2PC, que puede bloquearse indefinidamente si el coordinador falla después de enviar los mensajes de 'prepare' pero antes de los de 'commit', 3PC introduce una fase intermedia de 'pre-commit'. Las tres fases son: 1) CanCommit?: El coordinador pregunta a los participantes si pueden hacer commit. 2) PreCommit: Si todos responden afirmativamente, el coordinador les indica que se preparen para el commit, garantizando que la transacción puede ser completada o abortada de forma segura. 3) DoCommit: Finalmente, el coordinador ordena el commit definitivo. Esta fase adicional permite a los participantes decidir sobre el estado de la transacción (commit o abort) incluso si el coordinador original falla, asumiendo que no hay fallos de red que particionen a todos los nodos.
Aunque 3PC aborda algunas de las limitaciones de 2PC, su implementación en sistemas distribuidos de misión crítica es menos común debido a su mayor complejidad y a la suposición de que no hay particiones de red (network partitions) que aíslen a todos los nodos. Sistemas como Apache ZooKeeper o etcd, que proporcionan servicios de coordinación distribuida, suelen basarse en algoritmos de consenso más robustos como Paxos o Raft, que ofrecen garantías más fuertes frente a fallos arbitrarios y particiones de red. Sin embargo, el concepto de 3PC ha influido en el diseño de protocolos de coordinación y puede encontrarse en contextos específicos donde las suposiciones de red son más indulgentes o donde se necesita una recuperación más rápida de fallos del coordinador que la que ofrece 2PC.
Para un Arquitecto de Sistemas, entender 3PC es crucial para apreciar los trade-offs entre atomicidad, disponibilidad y complejidad en sistemas distribuidos. Si bien 3PC mejora la disponibilidad de 2PC ante fallos del coordinador, introduce una mayor latencia debido a las fases adicionales y no resuelve completamente el problema de las particiones de red, donde puede seguir habiendo incertidumbre. La elección entre 2PC, 3PC o algoritmos más avanzados como Paxos/Raft depende de los requisitos específicos de consistencia, disponibilidad y tolerancia a fallos del sistema. Un arquitecto debe evaluar cuidadosamente el modelo de fallos esperado y el impacto de la latencia antes de optar por un protocolo de commit, priorizando soluciones que ofrezcan las garantías necesarias con la menor complejidad operativa posible.