Transacciones Distribuidas
Este mapa conecta alternativas para coordinar cambios que no comparten un commit local. El punto de partida es el resultado que el negocio exige, los estados intermedios que admite y la recuperación que puede sostener.
Recorrido
| Documento | Pregunta de entrada |
|---|---|
| atomic-commit | ¿Qué significa que todos los participantes confirmen o aborten? |
| two-phase-commit | ¿Cómo se prepara y conserva una decisión entre recursos transaccionales? |
| saga-pattern | ¿Cómo completar o compensar una secuencia de commits locales? |
| try-confirm-cancel | ¿Puede el dominio reservar recursos y luego confirmarlos o liberarlos? |
atomic-commit define el problema; two-phase-commit presenta un protocolo para resolverlo. saga-pattern y try-confirm-cancel ofrecen contratos de negocio diferentes, no implementaciones equivalentes de un rollback global.
Síntesis para comparar
Las columnas resumen los modelos descritos en los canónicos. Las garantías concretas dependen de participantes, concurrencia, expiración y recuperación.
| Dimensión | two-phase-commit | saga-pattern | try-confirm-cancel |
|---|---|---|---|
| Idea principal | Coordinación de atomic commit. | Transacciones locales y compensación. | Reserva explícita y confirmación o cancelación. |
| Atomicidad | Resultado conjunto de las ramas participantes. | Commits locales; recuperación semántica del proceso. | Transiciones locales de reservas; el resultado conjunto depende del contrato. |
| Disponibilidad | Un preparado puede esperar una decisión inaccesible. | Pasos independientes pueden avanzar; el flujo puede quedar pendiente. | Participantes caídos retrasan resolución; reservas reducen capacidad disponible. |
| Bloqueo | Retención de estado y, frecuentemente, locks. | No necesita un lock global; puede retener recursos de negocio. | Retiene recursos reservados, sin exigir locks entre etapas. |
| Complejidad de negocio | Recursos deben admitir preparación y commit. | Requiere compensaciones y tratamiento de estados visibles. | Requiere operaciones Try/Confirm/Cancel compatibles. |
| Compensación y reservas | Abort de trabajo transaccional pendiente. | Nuevas acciones corrigen efectos confirmados. | Cancel libera reservas; reparar un Confirm final es otro problema. |
| Recuperación | Logs, decisiones durables y resolución de preparados. | Progreso durable, reintentos y compensaciones pendientes. | Estado de reservas, decisión durable, reintentos y arbitraje con expiración. |
| Latencia | Rondas de coordinación y persistencia. | Duración del flujo, incluyendo reparación. | Obtención de reservas y resolución posterior. |
| Operación | Preparados pendientes, locks y coordinador. | Procesos incompletos, compensaciones fallidas y efectos tardíos. | Reservas huérfanas, vencimientos y resultados mixtos. |
Preguntas para decidir
- ¿Puede simplificarse la frontera usando una transacción local?
- ¿Una ejecución parcial es inadmisible o puede corregirse después de ser observada?
- ¿Cada recurso puede preparar una transacción, reservar capacidad o compensar un efecto?
- ¿Qué cambios quedan fuera de la coordinación, como una API o acción física?
- ¿Cuánto puede esperar una decisión y quién resolverá su estado después de una caída?
- ¿Un timeout indica rechazo, incertidumbre o expiración de un compromiso?
La elección puede variar por frontera: un paso local de una saga puede usar una base de datos transaccional, y un flujo puede reservar recursos antes de un efecto irreversible. No hay una clasificación universal de «mejor» y «peor».
Conexiones con ejecución confiable
dual-write-problem identifica cambios independientes que pueden divergir. idempotency y deduplication ayudan ante reintentos, pero no hacen atómicos dos commits. at-least-once y delivery-guarantees delimitan el transporte; exactly-once-semantics permite revisar qué efecto y frontera reciben una garantía.
El MOC Reliable Execution and Delivery organiza ese recorrido complementario. Aquí la pregunta es cómo resolver un conjunto de cambios, no cuántas veces llega cada mensaje.
transactional-outbox conserva la intención de publicar junto a un cambio local; no coordina todos los pasos de saga-pattern. reliable-messaging conecta esa frontera con los efectos del consumidor y su recuperación operacional.
Alcance
Consenso, Raft y Paxos se desarrollarán en Distributed Systems / Coordination y se mencionan sin enlaces a IDs inexistentes. Las definiciones, ejemplos, fallos y fuentes de este cluster permanecen en los cuatro documentos canónicos; este mapa facilita navegar y comparar.