Two-Phase Commit (2PC) es un protocolo de consenso distribuido diseñado para lograr atomicidad en transacciones que involucran múltiples nodos o servicios. Opera en dos fases principales: la fase de 'preparación' (prepare phase) y la fase de 'confirmación' (commit phase). En la fase de preparación, un coordinador envía una solicitud de 'preparar' a todos los participantes. Cada participante ejecuta la transacción de forma provisional, registra los cambios en un log persistente y responde 'sí' si puede confirmar la transacción, o 'no' si no puede. Si el coordinador recibe un 'sí' de todos los participantes, pasa a la fase de confirmación. Si recibe al menos un 'no' o no recibe respuesta de algún participante dentro de un tiempo límite, aborta la transacción.
En el mundo real, 2PC ha sido implementado en diversos sistemas de gestión de bases de datos distribuidas y middleware de transacciones. Ejemplos notables incluyen sistemas de bases de datos relacionales tradicionales que soportan transacciones distribuidas como Oracle Database con su Distributed Transaction Coordinator (DTC), Microsoft SQL Server con Microsoft Distributed Transaction Coordinator (MSDTC), y PostgreSQL a través de su soporte para transacciones XA. También se ha utilizado en entornos de Enterprise Java Beans (EJB) y otros sistemas de procesamiento de transacciones (TP monitors) para coordinar transacciones a través de múltiples recursos. Sin embargo, su uso directo en microservicios modernos o sistemas NoSQL es menos común debido a sus limitaciones de rendimiento y disponibilidad.
Para un arquitecto, 2PC es crucial para entender los trade-offs entre consistencia, disponibilidad y rendimiento en sistemas distribuidos. Si bien garantiza una fuerte consistencia (atomicidad) para transacciones distribuidas, lo hace a expensas de la disponibilidad y el rendimiento. Es un protocolo bloqueante: si el coordinador falla después de la fase de preparación pero antes de la fase de confirmación, los participantes pueden quedar bloqueados esperando una decisión, lo que puede llevar a una interrupción del servicio. Además, su rendimiento se ve afectado por la latencia de red y el número de participantes, ya que requiere múltiples rondas de comunicación. Los arquitectos deben considerar alternativas como Sagas o compensaciones (compensating transactions) para lograr consistencia eventual en sistemas a gran escala que priorizan la disponibilidad y el rendimiento, reservando 2PC para escenarios donde la atomicidad estricta y la consistencia inmediata son requisitos ineludibles y el impacto en la disponibilidad es aceptable.