結果整合性が分散トランザクションよりも優れている理由 (Why Eventual Consistency Beats Distributed Transactions)

これら 8 つの章を通して、プロバイダーの抽象化から始まり、セマンティック イベント、エラー分類、再試行アルゴリズム、リース、調整、孤立した料金の最適化に進みました。これらすべての根底にある共通の疑問は、今では明確に問うことができます。「なぜ私たちはこのすべての複雑さに耐える必要があるのでしょうか?」 PSP、注文、財務記録を 1 つのトランザクションに統合して、これらすべての問題を一度に解決してみませんか?

答えは簡単かつ最終的です。PSP はトランザクションに参加できません。```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

## 最初に説明した概念```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 では、すべての参加者が同じコーディネーター、同じプロトコル、同じネットワーク信頼性を前提とすることが必要です。 PSP はこれらの仮定を一切受け入れません。PSP は制御不能なシステムであり、独自の SLA、独自の API、および独自のエラー モデルで実行されます。

## PSP が 2PC に参加できない理由

「準備」リクエストを PSP に送信してから「コミット」または「ロールバック」を送信したい場合でも、PSP はこの 2 フェーズ プロトコルをサポートしません。これは、カード自体、銀行ネットワーク、および不正行為チェックがすでに独自の (ほとんどの場合は 1 フェーズで) 決定を行っているためです。 PSP の API は、「後で決めるから待ってください」とは言いません。 「起こった」とか「起こらなかった」とか。システムで 2 番目のフェーズ (コミット) が失敗した場合、PSP にはトランザクションをロールバックするという概念がありません。ただし、別の返金リクエストがあり、それ自体は非同期で保証されていない操作です。```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ç
```## 佐賀: 地域の意思決定の連鎖

2PC に代わるアプローチは、各システムが独自のローカル トランザクションを実行し、イベントのみで次のステップに進むというものです。ステップが失敗した場合、前のステップは元に戻されません。それぞれが独自の代償作用によって修正されます。```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
```これは、このシリーズの前半で見た「キャプチャは簡単だが、ファイナライズは難しい」という真実の直接の結果です。ファイナライゼーションの難しさは、まさに物語の補償ステップの設計の難しさです。

## コベナント: 物語のセーフティネット

Saga は、補償手順が常に機能することを保証しません。補償リクエストが失敗したり、ネットワークがダウンしたり、ワーカーがクラッシュしたりする可能性もあります。したがって、前の章で確立したもの (リース、コンセンサスワーカー、孤立した料金の改善) はすべて、サーガだけでは不十分な瞬間をクリーンアップする 2 番目のレイヤーです。```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
```## 最終的な整合性の実際のコスト: 整合性ではなくウィンドウ

最終的な整合性は、「ある時点でデータが不正確になる可能性がある」という意味ではありません。これは、「一定期間、データが不完全または古い可能性がありますが、この期間は測定され、制限されている」ことを意味します。このウィンドウは製品側で表示される必要があります。顧客が支払いを行った後、注文ステータスが表示されるまでに何秒/分かかりますか?これは技術的なものではなく、製品に関する決定であり、このシリーズの開始以来私たちが主張してきたことの本質です。分散型決済システムにおける完全な瞬間的一貫性は幻想です。本当の目標は、測定され、観察可能な不一致の範囲を短くすることです。

|アプローチ |保証 |実際に可能ですか |
| --- | --- | --- |
| 2PC(PSP含む) |即時の完全な一貫性 |いいえ — PSP は参加できません |
|佐賀+補償 |段階的に進捗、遡及修正 |はい |
|佐賀+和解 |中程度の限られた不整合ウィンドウ |はい — このシリーズが推奨するモデル |

## 混同されやすい区別```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
```## 2PCとSaga+Reconciliationの比較

|基準 | 2PC |佐賀+和解 |
| --- | --- | --- |
| PSP への関与 |必要だが不可能 |不要 |
|ロックアウト時間 |参加者全員 |なし |
|部分的なフォールト トレランス |低い |高 |
|運用の複雑さ |理論的には低く、実際には不可能 |高いけど本物 |

## このモデルを評価する際のチェックリスト

1. システム内のすべての外部依存関係 (PSP を含む) は同じトランザクション プロトコルに参加できますか?参加できない場合、2PC はオプションではありません。
2. 物語の各ステップには、明確に定義された代償アクションがありますか?
3. 是正措置が失敗した場合はどうなりますか? それは静かに消えるのでしょうか、それともコンセンサスによって捕捉されるのでしょうか?
4. 最終整合性ウィンドウは測定され、製品チームと共有されていますか?
5. システムは、「常に一貫している」という幻想ではなく、「短時間で一貫している」という現実を目指していますか?

## これら 8 つの章から覚えておくべきこと

1. PSP は外部システムであり、トランザクション プロトコルに参加することはできません。だからこそ2PCは罠なのです。
2. Saga は、各ステップが独自のローカル トランザクションと独自の補償アクションを実行する現実的な代替案です。
3. コンセンサスはサーガの欠点ではなく、分散システムに固有の永続的なセーフティ ネットです。
4. 不整合ではなく、最終的な整合性。これは、測定され観察可能な収束の窓です。

> 完全な瞬間的な一貫性は、分散型決済システムで求められるものではありません。求められているのは、不一致がどれくらいの期間続くかを正確に知ることです。

これは、プロバイダーの抽象化から始まった 8 つの部分からなるパスの結論です。SDK リークの防止、セマンティック イベントの生成、エラーの正確な分類、再試行の規律の確立、リースによる作業の安全な所有、コンセンサスによるドリフトの捕捉、証明による孤立請求の解決など、すべてが同じ 1 つの真実に役立ちます。つまり、分散型決済システムは完璧を目指すのではなく、管理され観察可能な不整合を目指すということです。