Pourquoi la cohérence finale est supérieure à la transaction distribuée (Pourquoi La Coherence Finale Est Superieure A La Transaction Distribuee)

Tout au long de ces huit chapitres, nous avons commencé par l'abstraction du fournisseur et avons progressé vers les événements sémantiques, la taxonomie des erreurs, les algorithmes de nouvelle tentative, le bail, le rapprochement et l'optimisation des frais orphelins. La question commune qui les sous-tend tous peut désormais être posée clairement : pourquoi supportons-nous toute cette complexité ? Pourquoi ne combinons-nous pas les dossiers PSP, de commande et financiers en une seule transaction et ne résolvons-nous pas tous ces problèmes en même temps ?

La réponse est simple et définitive : PSP ne pourra jamais participer à votre transaction.```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

## Concepts à la première mention```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 exige que tous les participants aient le même coordinateur, le même protocole et la même hypothèse de fiabilité du réseau. La PSP n'accepte aucune de ces hypothèses : il s'agit d'un système hors de votre contrôle, fonctionnant selon son propre SLA, sa propre API et son propre modèle d'erreur.

## Pourquoi la PSP ne peut pas rejoindre 2PC

Même si vous souhaitez envoyer une demande de « préparation » à une PSP, puis envoyer un « commit » ou un « rollback », la PSP ne prend pas en charge ce protocole en deux phases, car la carte elle-même, le réseau bancaire et le contrôle de fraude prennent déjà leur propre décision (principalement en une seule phase). L'API de la PSP ne vous dit pas « attendez, je déciderai plus tard » ; Il dit « c'est arrivé » ou « cela n'est pas arrivé ». Si la deuxième phase (validation) échoue sur votre système, il n'est pas possible pour PSP d'annuler la transaction ; Cependant, il existe une demande de remboursement distincte, qui est elle-même une opération asynchrone et non garantie.```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 : chaîne de décisions locales

L'approche qui remplace 2PC est que chaque système exécute sa propre transaction locale et passe à l'étape suivante uniquement avec l'événement. Si une étape échoue, les étapes précédentes ne sont pas annulées ; chacun est corrigé par sa propre action compensatoire.```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
```C'est le résultat direct de la vérité « la capture est facile, la finalisation est difficile » que nous avons vu plus tôt dans cette série : la difficulté de la finalisation est précisément la difficulté de concevoir les étapes de compensation de la saga.

## Covenant : le filet de sécurité de la saga

Saga ne garantit pas que les étapes d'indemnisation fonctionneront toujours : la demande d'indemnisation peut également échouer, le réseau peut tomber en panne, le travailleur peut planter. Ainsi, tout ce que nous avons établi dans les chapitres précédents (bail, consensus, amélioration des charges orphelines) est une deuxième couche qui nettoie les moments où la saga seule ne suffit pas.```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
```## Le vrai coût de la cohérence événementielle : la fenêtre, pas la cohérence

La cohérence à terme ne signifie pas que « les données peuvent être inexactes à un moment donné » ; Cela signifie que « les données peuvent être incomplètes ou obsolètes pendant une période donnée, mais cette période est mesurée et limitée ». Cette fenêtre doit être visible côté produit : combien de secondes/minutes faut-il pour que le statut de la commande apparaisse après le paiement du client ? Il s'agit d'une décision de produit, pas d'un détail technique, et c'est l'essence de ce que nous préconisons depuis le début de cette série : la parfaite cohérence instantanée dans un système de paiement distribué est une illusion ; Le véritable objectif est une fenêtre de divergence courte, mesurée et observable.

| Approche | Garantie | Est-ce réellement possible |
| --- | --- | --- |
| 2PC (y compris PSP) | Cohérence instantanée et totale | Non — PSP ne peut pas participer |
| Saga + compensation | Progression étape par étape, correction rétroactive | Oui |
| Saga + Réconciliation | Fenêtre d'incohérence modérée et limitée | Oui, le modèle recommandé par cette série |

## Distinctions souvent confuses```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
```## Comparaison entre 2PC et Saga+Réconciliation

| Critère | 2 pièces | Saga + Réconciliation |
| --- | --- | --- |
| Implication des PSP | Nécessaire mais pas possible | Non requis |
| Temps de verrouillage | À travers tous les participants | Aucun |
| Tolérance partielle aux pannes | Faible | Élevé |
| Complexité opérationnelle | Faible en théorie, impossible en pratique | Élevé mais réel |

## Liste de contrôle lors de l'évaluation de ce modèle

1. Toutes les dépendances externes (y compris les PSP) du système peuvent-elles participer au même protocole de transaction ? Si vous ne pouvez pas assister au 2PC, ce n'est pas une option.
2. Chaque étape de la saga a-t-elle une action compensatoire clairement définie ?
3. Que se passe-t-il lorsque les mesures correctives échouent : disparaissent-elles silencieusement ou font-elles l’objet d’un consensus ?
4. La fenêtre de cohérence éventuelle est-elle mesurée et partagée avec l'équipe produit ?
5. Le système vise-t-il la réalité d'une « cohérence dans un court laps de temps » plutôt que l'illusion d'une « cohérence à tout moment » ?

## Ce qu'il faut retenir de ces huit chapitres

1. PSP est un système externe et ne peut jamais participer à votre protocole de transaction ; C'est pourquoi 2PC est un piège.
2. Saga est une alternative réaliste où chaque étape exécute sa propre transaction locale et sa propre action de compensation.
3. Le consensus n'est pas un défaut de la saga, mais un filet de sécurité permanent inhérent aux systèmes distribués.
4. Cohérence éventuelle, et non incohérence ; Il s’agit d’une fenêtre de convergence mesurée et observable.

> Une parfaite cohérence instantanée n'est pas ce qui est recherché dans un système de paiement distribué ; Ce que l’on cherche, c’est de savoir précisément combien de temps durera l’écart.

C'est la conclusion d'un chemin en huit parties qui a commencé avec l'abstraction du fournisseur : prévenir les fuites du SDK, générer des événements sémantiques, classer correctement les erreurs, discipliner les nouvelles tentatives, posséder le travail en toute sécurité avec les baux, détecter les dérives grâce au consensus et remédier aux frais orphelins avec des preuves - tous servent la même vérité : un système de paiement distribué ne vise pas la perfection, mais une incohérence contrôlée et observable.