Transacciones Distribuidas

Resumen

En un monolito, una transacción es simple: BEGIN, operás, COMMIT. Si algo falla, ROLLBACK. Todo ocurre en una sola base de datos. En un sistema distribuido, una transacción puede requerir escribir en la base de datos de order-service, la de payment-service y la de inventory-service. Hacer que las tres operaciones sean atómicas es el problema de las transacciones distribuidas.

Hay dos enfoques principales:

Two-Phase Commit (2PC): un coordinador pide a todos los participantes que se preparen para commitear —fase 1—. Si todos responden OK, les ordena commitear —fase 2—. Si alguno falla, todos hacen rollback. Garantiza atomicidad fuerte pero es lento y bloqueante.

Saga: cada paso es una transacción local con un paso de compensación. Si un paso falla, se ejecutan las compensaciones de los pasos anteriores. No es atómica en sentido estricto —entre el paso y su compensación hay inconsistencias visibles—, pero es mucho más escalable.

Alcance y supuestos

Este paquete cubre transacciones distribuidas, Two-Phase Commit y Saga como alternativas arquitectónicas. Asume familiaridad con bases de datos y microservicios.

Modelo mental

Dos personas firmando un contrato en distintas ciudades. Con 2PC, las dos están al teléfono: «¿estás listo para firmar?» —«sí»— «¿vos también?» —«sí»— «firmá ahora». Con Saga, cada uno firma cuando puede, y si el otro se arrepiente, hay un proceso de rescisión.

Uso práctico

• ✅ 2PC para sistemas donde la consistencia fuerte es no negociable —bancos centrales—.
• ✅ Saga para la mayoría de los sistemas distribuidos modernos —ecommerce, reservas—.
• ❌ 2PC en sistemas de alta disponibilidad: el coordinador es un punto único de falla y los locks degradan el throughput.

Ejemplo trabajado: 2PC en un sistema bancario

Un banco central procesa transferencias entre dos bancos. El coordinador 2PC pide a ambos bancos que reserven fondos —fase prepare—. Si ambos confirman, ordena commit. Si uno falla —fondos insuficientes—, ordena rollback a ambos. La consistencia fuerte es no negociable: ninguna cuenta queda con débito sin crédito. El costo en latencia y disponibilidad se acepta por requisito regulatorio.

Evidencia

• Two-Phase Commit está estandarizado en XA. El patrón Saga fue formalizado por Hector Garcia-Molina en 1987 y es la base de las transacciones distribuidas en microservicios modernos.