Por qué la coherencia eventual es superior a las transacciones distribuidas (Por Que La Coherencia Eventual Es Superior A Las Transacciones Distribuidas)

A lo largo de estos ocho capítulos, comenzamos con la abstracción de proveedores y avanzamos hacia eventos semánticos, taxonomía de errores, algoritmos de reintento, arrendamiento, conciliación y optimización de cargos huérfanos. La pregunta común que subyace a todos ellos ahora puede plantearse claramente: ¿Por qué soportamos toda esta complejidad? ¿Por qué no combinamos PSP, pedidos y registros financieros en una sola transacción y solucionamos todos estos problemas a la vez?

La respuesta es simple y definitiva: PSP nunca puede participar en su transacción.```text 2PC'nin gerektirdiği Coordinator ←→ Participant 1 (Order DB) Coordinator ←→ Participant 2 (Finance DB) Coordinator ←→ Participant 3 (PSP??)

Gerçek dünyada PSP Kendi transaction protokolünü çalıştırmaz Kendi ağ sınırında, kendi tutarlılık modeliyle yaşar Sizin 'prepare' veya 'commit' sinyalinizi anlamaz

## Conceptos en la primera mención```text
📦 Two-Phase Commit (2PC)
Birden fazla katılımcının bir işlemi ya tamamen kabul (commit) ya da tamamen reddetmesini (rollback) sağlayan protokol.

📦 Saga
Tek bir ACID transaction'a sığmayan bir iş akışını, her adımın kendi telafi (compensation) adımına sahip olduğu bir dizi yerel işleme bölen desen.

📦 Eventual Consistency
Sistemin her an tutarlı olmayabileceğini, ama belirli bir süre içinde tutarlı bir duruma yakınsayacağını kabul eden model.

📦 Reconciliation olarak backstop
Saga'nın telafi adımları başarısız olduğunda veya atlandığında, sistemi gerçek duruma geri getiren son güvenlik ağı.
```2PC requiere que todos los participantes tengan el mismo coordinador, el mismo protocolo y la misma suposición de confiabilidad de la red. PSP no acepta ninguna de estas suposiciones: es un sistema fuera de su control, que se ejecuta según su propio SLA, su propia API y su propio modelo de error.

## ¿Por qué PSP no puede unirse a 2PC?

Incluso si desea enviar una solicitud de "preparación" a un PSP y luego enviar una "confirmación" o una "reversión", el PSP no admite este protocolo de dos fases, porque la tarjeta en sí, la red bancaria y el control de fraude ya toman su propia decisión (principalmente de una sola fase). La API de PSP no te dice "espera, lo decidiré más tarde"; Dice "sucedió" o "no sucedió". Si la segunda fase (compromiso) falla en su sistema, no existe el concepto de que PSP revierta la transacción; Sin embargo, existe una solicitud de reembolso separada, que en sí misma es una operación asincrónica y no garantizada.```text
2PC'nin varsaydığı dünya
  Prepare → tüm katılımcılar 'hazırım' der → Commit → hepsi aynı anda kabul eder

PSP'nin gerçek dünyası
  Charge isteği → PSP kendi kararını anında verir → sonuç kesindir
  Geri almak istersen → ayrı bir Refund isteği, ayrı bir asenkron süreç
```## Saga: cadena de decisiones locales

El enfoque que reemplaza a 2PC es que cada sistema ejecuta su propia transacción local y pasa al siguiente paso solo con el evento. Si un paso falla, los pasos anteriores no se deshacen; cada uno se corrige mediante su propia acción compensatoria.```text
Charge PSP'de başarılı
  → sipariş oluştur (yerel transaction)
  → finans kaydı oluştur (yerel transaction)

Finans kaydı başarısız olursa
  → sipariş için telafi: siparişi iptal et
  → PSP için telafi: refund isteği gönder
```Este es un resultado directo de la verdad de que "la captura es fácil, la finalización es difícil" que vimos anteriormente en esta serie: la dificultad de la finalización es precisamente la dificultad de diseñar los pasos de compensación de la saga.

## Covenant: la red de seguridad de la saga

Saga no garantiza que los pasos de compensación siempre funcionen: la solicitud de compensación también puede fallar, la red puede caer y el trabajador puede fallar. Así que todo lo que establecimos en los capítulos anteriores (arrendamiento, trabajador de consenso, mejora de cargos huérfanos) es una segunda capa que limpia los momentos en los que la saga por sí sola no es suficiente.```text
Saga (birincil yol)
  → adım adım ilerler, her adım kendi telafisine sahiptir

Reconciliation (ikincil güvenlik ağı)
  → saga'nın atladığı veya başarısız olduğu durumları periyodik olarak tarar ve düzeltir
```## El coste real de la coherencia eventual: ventana, no coherencia

La coherencia eventual no significa que "los datos puedan ser inexactos en algún momento"; Significa que "los datos pueden estar incompletos o desactualizados durante un período de tiempo, pero este período es medido y limitado". Esta ventana debe estar visible en el lado del producto: ¿cuántos segundos/minutos pueden tardar en aparecer el estado del pedido después de que el cliente paga? Esta es una decisión de producto, no un tecnicismo, y es la esencia de lo que hemos estado defendiendo desde el comienzo de esta serie: la consistencia instantánea perfecta en un sistema de pago distribuido es una ilusión; El verdadero objetivo es una ventana de discrepancia breve, medida y observable.

| Enfoque | Garantía | ¿Es realmente posible?
| --- | --- | --- |
| 2 piezas (incluida PSP) | Consistencia total e instantánea | No, PSP no puede participar |
| Saga + compensación | Progreso paso a paso, corrección retroactiva | Sí |
| Saga + Reconciliación | Ventana de inconsistencia moderada y limitada | Sí, el modelo que recomienda esta serie |

## Distinciones frecuentemente confusas```text
❌ Eventual consistency = tutarsız sistem
✓ Eventual consistency = ölçülü, sınırlı bir pencere içinde tutarlılığa yakınsama

❌ Saga, 2PC'nin daha basit bir versiyonudur
✓ Saga farklı bir modeldir: geri alma yoktur, telafi vardır

❌ Mutabakat, saga'nın tasarım hatasını gösterir
✓ Mutabakat, dağıtık sistemin doğasında olan kalıcı bir güvenlik ağıdır, saga'nın eksikliği değil
```## Comparación entre 2PC y Saga+Reconciliation

| Criterio | 2 piezas | Saga + Reconciliación |
| --- | --- | --- |
| Participación de la PSP | Necesario pero no posible | No requerido |
| Tiempo de bloqueo | A lo largo de todos los participantes | Ninguno |
| Tolerancia parcial a fallos | Bajo | Alto |
| Complejidad operativa | Bajo en teoría, imposible en la práctica | Alto pero real |

## Lista de verificación al evaluar este modelo

1. ¿Pueden todas las dependencias externas (incluido PSP) del sistema participar en el mismo protocolo de transacción? Si no puede asistir, 2PC no es una opción.
2. ¿Cada paso de la saga tiene una acción compensatoria claramente definida?
3. ¿Qué sucede cuando las medidas correctivas fracasan? ¿Desaparecen silenciosamente o son capturadas por consenso?
4. ¿Se mide y se comparte la ventana de coherencia final con el equipo de producto?
5. ¿Apunta el sistema a la realidad de ser "consistente en un corto tiempo" en lugar de la ilusión de "consistente en todo momento"?

## Lo que debes recordar de estos ocho capítulos

1. PSP es un sistema externo y nunca puede participar en su protocolo de transacción; Por eso 2PC es una trampa.
2. Saga es una alternativa realista donde cada paso ejecuta su propia transacción local y su propia acción de compensación.
3. El consenso no es un defecto de la saga, sino una red de seguridad permanente inherente a los sistemas distribuidos.
4. Consistencia eventual, no inconsistencia; Es una ventana de convergencia medida y observable.

> La perfecta coherencia instantánea no es lo que se busca en un sistema de pago distribuido; Lo que se busca es saber con precisión cuánto durará la discrepancia.

Esta es la conclusión de un camino de ocho partes que comenzó con la abstracción del proveedor: prevenir fugas de SDK, generar eventos semánticos, clasificar errores correctamente, disciplinar los reintentos, poseer el trabajo de manera segura con arrendamientos, captar la deriva con consenso y solucionar cargos huérfanos con pruebas: todo sirve a la misma verdad: un sistema de pago distribuido no apunta a la perfección, sino a una inconsistencia controlada y observable.