Ödeme Kurtarma Pipeline ve Runbook (Odeme Kurtarma Pipeline Ve Runbook)

Önceki bölümde payment id ile korelasyon, step event log ve deferred finalize metriklerinin operasyonu nasıl beslediğini gördük. Bu bölüm, o görünürlüğün üzerine inşa edilen recovery pipeline'ı ele alıyor: bir ödeme takıldığında sistem önce kendi kendine ne yapabilir, ne zaman insan devreye girer?

İyi bir recovery pipeline'ın ilkesi basittir: otomasyon önce. Reconciliation worker, stuck watcher, retry worker — bunlar insan müdahalesi gerektirmeden çoğu sürüklenmeyi temizler. İnsan runbook'ları yalnızca otomasyonun uniqueness duvarlarına veya belirsiz kanıta çarptığı anlarda devreye girer.

Ödeme takıldı
  → otomatik: reconciliation scan
  → otomatik: retry with backoff
  → otomatik: PSP status query
  → insan: uniqueness wall / ambiguous evidence

Kavramlar ilk geçtiği yerde

📦 Recovery Pipeline
Takılan veya tutarsız ödemeleri otomatik olarak teşhis edip düzeltmeye çalışan ardışık işlem hattı.

📦 Uniqueness Wall
Veritabanı benzersizlik kısıtının, güvenli replay veya heal girişimini engellediği durum.

📦 Evidence-Driven Runbook
Her adımın hangi kanıta (step log, PSP sorgusu, audit) dayandığını tanımlayan operasyon kılavuzu.

📦 Manual Review Queue
Otomasyonun çözemediği kayıtların biriktiği, görünür bekleme alanı.

Runbook 'ne yapılır' sorusuna cevap verir; evidence-driven runbook 'hangi kanıt olmadan yapılmaz' sorusuna cevap verir.

Otomasyon önce: recovery pipeline katmanları

Recovery pipeline tek bir worker değil, birbirini tamamlayan katmanlardır. Her katman bir öncekinin çözemediğini ele alır; hiçbiri bir sonrakinin işini yapmaya kalkmamalıdır.

Katman 1: Retry worker
  → transient hataları backoff ile tekrar dener

Katman 2: Stuck watcher
  → lease süresi dolmuş, Processing'de kalan kayıtları sıfırlar

Katman 3: Reconciliation sweeper
  → aged FinalizePending / Expired kayıtları PSP ile karşılaştırır

Katman 4: Manual review queue
  → otomasyonun çözemediği kayıtlar

Katman 1-3 tamamen otomatiktir ve günün büyük bölümünde yeterlidir. Katman 4, pipeline'ın başarısızlığı değil, sınırının görünür olmasıdır.

Uniqueness duvarı: otomasyonun durduğu yer

Bir reconciliation worker PSP'den 'Succeeded' görür ve local kaydı Captured yapmaya çalışır — ama veritabanında aynı idempotency key ile zaten bir Captured satırı vardır. Insert veya update başarısız olur; otomasyon durur.

Reconciliation: payment #5521 → PSP says Captured
  → local UPDATE attempt
  → UNIQUE constraint violation on idempotency_key
  → otomasyon durur
  → manual review queue'ya yaz

Bu bir bug değil, koruma mekanizmasıdır. Uniqueness duvarı, çift finalize'ı engeller — ama aynı zamanda otomasyonun 'sorunu çözdüm' demesini de engeller. İşte tam bu noktada kanıta dayalı runbook devreye girer.

Kanıta dayalı runbook: refleks değil, prosedür

İnsan müdahalesi gerektiğinde runbook şu sırayı izler:

1. Step event log'u oku (payment id ile)
2. PSP status query yap (provider gateway üzerinden)
3. Local kayıtları karşılaştır (payment, order, idempotency)
4. Kanıt tablosunu doldur
5. Karar: heal / refund / no-action
6. Audit kaydı yaz

Runbook'taki her karar noktası bir kanıt gerektirir. 'PSP Captured diyor ama local Expired' → heal adayı. 'PSP Not Found, local Processing' → refund adayı değil, bekle veya escalate. 'İki Captured satırı, farklı idempotency key' → çift charge, refund birini.

Manual review queue: görünür bekleme

Otomasyonun çözemediği kayıtlar sessizce kaybolmamalıdır. Manual review queue, bu kayıtların biriktiği, yaşlandığı ve önceliklendirildiği görünür bir alandır.

Alan	Amaç
paymentId	Korelasyon
stuckReason	UniquenessWall / AmbiguousEvidence / PSPUnknown
evidenceSummary	Step log + PSP query özeti
age	Ne kadar süredir bekliyor
priority	Tutar, müşteri şikayeti, SLA

Queue'daki her kayıt bir runbook adımıyla eşleşmelidir; operatör 'ne yapacağım' sorusunu queue'dan okuyabilmelidir.

Runbook örneği: uniqueness wall sonrası

Durum: reconciliation Captured yazamadı — idempotency_key conflict

Kanıt toplama:
  □ Step log: FinalizeAttempted iki kez mi?
  □ Mevcut Captured satırı hangi webhook'tan geldi?
  □ PSP query: kaç charge var bu correlation id ile?

Karar ağacı:
  → Tek PSP charge, local çift satır → eski satırı audit ile kapat
  → İki PSP charge → birini refund et (runbook: duplicate charge)
  → PSP charge yok → local Captured yanlış → escalate

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

❌ Manual review queue = otomasyon başarısız oldu
✓ Manual review queue = otomasyonun sınırı görünür ve güvenli

❌ Runbook = deneyimli mühendisin sezgisi
✓ Runbook = kanıt tabanlı, tekrarlanabilir prosedür

❌ Uniqueness wall kaldırılmalı
✓ Uniqueness wall korunmalı; runbook duvarın ötesini yönetir

Otomasyon vs insan müdahalesi

Durum	Otomasyon	İnsan runbook
Transient timeout	Retry worker	Gerekmez
Aged FinalizePending	Reconciliation	Gerekmez
Idempotency conflict	Durur, queue'ya yazar	Kanıt topla, karar ver
Ambiguous PSP response	Durur, queue'ya yazar	Escalate veya bekle

Recovery pipeline kontrol listesi

1. Retry, stuck watcher ve reconciliation katmanları ayrı mı ve sıralı mı çalışıyor?
2. Uniqueness constraint ihlali otomatik olarak manual review queue'ya yazılıyor mu?
3. Her runbook adımı hangi kanıtı gerektirdiğini açıkça tanımlıyor mu?
4. Manual review queue'daki kayıtlar yaş ve öncelik ile sıralanıyor mu?
5. İnsan müdahalesi sonrası audit kaydı ve step event log girişi zorunlu mu?
6. Otomasyonun çözdüğü oran metrik olarak izleniyor mu (automation_resolution_rate)?

Bu yazıdan aklında ne kalmalı

1. Recovery pipeline otomasyon önce prensibiyle katmanlıdır; insan son çaredir.
2. Uniqueness duvarı otomasyonu durdurur — bu koruma, bug değildir.
3. Runbook kanıta dayalı olmalı; refleks aksiyon tehlikelidir.
4. Manual review queue, çözülemeyen kayıtların sessizce kaybolmasını engeller.

İyi bir recovery pipeline, insan müdahalesini sıfıra indirmeye çalışmaz — insan müdahalesini doğru an, doğru kanıt ve doğru prosedürle sınırlar.

Bir sonraki bölümde messaging katmanına iniyoruz: exactly-once bir yalan; effectively-once iş sonucu defense in depth ile nasıl elde edilir?