Neden Eventual Consistency Dağıtık Transaction'dan Üstün (Neden Eventual Consistency Dagitik Transactiondan Ustu)

Bu sekiz bölüm boyunca provider abstraction'dan başlayıp semantik event'lere, hata taksonomisine, retry algoritmalarına, lease'e, mutabakata ve orphan charge iyileştirmesine kadar ilerledik. Hepsinin altında yatan ortak soru şimdi açıkça sorulabilir: Neden bunca karmaşıklığa katlanıyoruz? Neden PSP, sipariş ve finans kayıtlarını tek bir transaction'da birleştirip bu sorunların hepsini bir kerede çözmüyoruz?

Cevap basit ve nihai: PSP, sizin transaction'ınıza hiçbir zaman katılamaz.

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

Kavramlar ilk geçtiği yerde

📦 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, tüm katılımcıların aynı coordinator'a, aynı protokole ve aynı ağ güvenilirlik varsayımına sahip olmasını gerektirir. PSP bu varsayımların hiçbirini kabul etmez — kendi SLA'sı, kendi API'si ve kendi hata modeliyle çalışan, sizin kontrolünüz dışında bir sistemdir.

PSP'nin 2PC'ye neden katılamayacağı

Bir PSP'ye 'prepare' isteği gönderip sonra 'commit' veya 'rollback' göndermek isteseniz bile, PSP bu iki fazlı protokolü desteklemez — çünkü kartın kendisi, banka ağı ve dolandırıcılık kontrolü zaten kendi (çoğu zaman tek fazlı) kararını verir. PSP'nin API'si size 'sonra karar vereceğim, bekle' demez; 'oldu' veya 'olmadı' der. İkinci fazın (commit) sizin sisteminizde başarısız olması durumunda, PSP'nin işlemi geri alması diye bir kavram yoktur; ancak ayrı bir refund isteği vardır — ki bu da kendi başına asenkron, garantisiz bir işlemdir.

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: yerel kararların zinciri

2PC'nin yerini alan yaklaşım, her sistemin kendi yerel transaction'ını yürütüp, bir sonraki adıma yalnızca event ile ilerlemesidir. Bir adım başarısız olursa, önceki adımlar geri alınmaz; her biri kendi telafi eylemiyle düzeltilir.

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

Bu, bu serinin başlarında gördüğümüz 'capture kolay, finalization zor' gerçeğinin doğrudan sonucudur: finalization'ın zorluğu, tam olarak saga'nın telafi adımlarını tasarlamanın zorluğudur.

Mutabakat: saga'nın güvenlik ağı

Saga, telafi adımlarının her zaman çalışacağını garanti etmez — telafi isteği de başarısız olabilir, ağ kopabilir, worker çökebilir. Bu yüzden önceki bölümlerde kurduğumuz her şey (lease, mutabakat worker, orphan charge iyileştirme) saga'nın tek başına yetmediği anları temizleyen ikinci bir katmandır.

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

Eventual consistency'nin gerçek maliyeti: tutarsızlık değil, pencere

Eventual consistency, 'veri bir süre yanlış olabilir' demek değildir; 'veri bir süre eksik veya güncel olmayabilir, ama bu süre ölçülür ve sınırlanır' demektir. Bu pencerenin ürün tarafında görünür olması gerekir: müşteri ödeme yaptıktan sonra sipariş durumunun görünmesi kaç saniye/dakika sürebilir? Bu bir teknik detay değil, bir ürün kararıdır ve bu serinin başından beri savunduğumuz şeyin özüdür: dağıtık bir ödeme sisteminde mükemmel anlık tutarlılık bir yanılsamadır; gerçek hedef, kısa, ölçülü ve gözlemlenebilir bir tutarsızlık penceresidir.

Yaklaşım	Garanti	Gerçekte mümkün mü
2PC (PSP dahil)	Anlık, tam tutarlılık	Hayır — PSP katılamaz
Saga + telafi	Adım adım ilerleme, geri dönük düzeltme	Evet
Saga + Reconciliation	Ölçülü, sınırlı tutarsızlık penceresi	Evet — bu serinin önerdiği model

Sık karıştırılan ayrımlar

❌ 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 ile Saga+Reconciliation karşılaştırması

Kriter	2PC	Saga + Reconciliation
PSP'nin katılımı	Gerekli ama mümkün değil	Gerekmiyor
Kilitlenme süresi	Tüm katılımcılar boyunca	Yok
Kısmi arızaya dayanıklılık	Düşük	Yüksek
Operasyonel karmaşıklık	Teoride düşük, pratikte imkansız	Yüksek ama gerçek

Bu modeli değerlendirirken kontrol listesi

1. Sistemdeki her dış bağımlılık (PSP dahil) aynı transaction protokolüne katılabiliyor mu? Katılamıyorsa 2PC bir seçenek değildir.
2. Her saga adımının açıkça tanımlanmış bir telafi eylemi var mı?
3. Telafi eylemi başarısız olduğunda ne olur — sessizce mi kaybolur, yoksa mutabakat tarafından mı yakalanır?
4. Eventual consistency penceresi ölçülüyor ve ürün ekibiyle paylaşılıyor mu?
5. Sistem, 'her an tutarlı' yanılsaması yerine 'kısa sürede tutarlı' gerçeğini mi hedefliyor?

Bu sekiz bölümden aklında ne kalmalı

1. PSP dış bir sistemdir ve hiçbir zaman sizin transaction protokolünüze katılamaz; 2PC bu yüzden bir tuzaktır.
2. Saga, her adımın kendi yerel transaction'ını ve kendi telafi eylemini yürüttüğü gerçekçi bir alternatiftir.
3. Mutabakat, saga'nın eksikliği değil, dağıtık sistemlerin doğasında olan kalıcı bir güvenlik ağıdır.
4. Eventual consistency, tutarsızlık değil; ölçülü, gözlemlenebilir bir yakınsama penceresidir.

Dağıtık bir ödeme sisteminde aranan şey mükemmel anlık tutarlılık değildir; aranan şey, tutarsızlığın ne kadar süreceğini kesin olarak bilmektir.

Bu, provider abstraction'dan başlayan sekiz bölümlük yolun kapanışıdır: SDK sızıntısını önlemek, semantik event'ler üretmek, hatayı doğru sınıflamak, retry'ı disiplinli yapmak, lease ile işi güvenle sahiplenmek, sürüklenmeyi mutabakatla yakalamak ve orphan charge'ları kanıtla iyileştirmek — hepsi aynı tek gerçeğe hizmet eder: dağıtık bir ödeme sistemi, mükemmelliği değil, kontrollü ve gözlemlenebilir bir tutarsızlığı hedefler.