Production Ödeme Motoru Tasarlamak (Production Odeme Motoru Tasarlamak)

Bu seri, provider abstraction'dan başlayıp webhook güvenilirliğine, idempotency'ye, saga'ya, lease'e, mutabakata, observability'ye, recovery pipeline'a ve effectively-once işlemeye kadar uzandı. Bu son teknik bölüm, o yolculuğun sentezidir: production'da çalışan bir ödeme motoru tasarlıyorsanız, hangi kararları hangi sırayla vermelisiniz?

Checklist bir feature listesi değildir. Her madde, serinin bir veya daha fazla bölümünde savunulan bir ilkenin ölçülebilir testidir. 'Idempotency var mı' değil; 'idempotency key API, webhook dedup ve DB uniqueness üçlüsü birlikte mi çalışıyor' sorusudur.

Production Payment Engine
  ├─ Boundaries (orchestrator ↔ gateway)
  ├─ State & Evidence
  ├─ Reliability (retry, lease, outbox)
  ├─ Recovery (reconciliation, runbooks)
  └─ Observability (payment id, step log, metrics)

Kavramlar ilk geçtiği yerde

📦 Checkout Orchestrator
Ödeme niyetini yöneten, semantik sonuç gören, PSP detayı bilmeyen servis.

📦 Provider Gateway
PSP SDK'sını, webhook çevirisini ve provider'a özgü akışları sahiplenen servis.

📦 Production Readiness
Sistemin sadece happy path'te değil, arıza, yarış ve sürüklenme anlarında da doğru davranması.

📦 Architectural Checklist
Tasarım kararlarının ölçülebilir, evet/hayır testlerine dönüştürülmüş hali.

Production ödeme motoru, 'charge API'si çalışıyor' demek değildir; 'charge başarısız olduğunda, webhook geç geldiğinde, worker çöktüğünde ne oluyor' sorusuna cevap vermektir.

1. Sınırlar: SDK sızıntısı yok

• Checkout orchestrator hiçbir PSP SDK tipini import etmiyor mu?
• Orchestrator yalnızca semantik ChargeRequest / ChargeResult görüyor mu?
• Webhook downstream'e ham provider payload olarak mı, semantik event olarak mı ulaşıyor?
• Provider gateway, provider event → semantik event eşleme tablosunun tek sahibi mi?
• Yeni bir PSP eklemek orchestrator kodunda sıfır satır değişiklik gerektiriyor mu?

Bu bölüm serinin 9-10. bölümlerinin özüdür. Sınır kırılırsa, geri kalan her katman o sızıntının üzerine inşa edilir.

2. Durum ve kanıt: state ≠ evidence

• Payment state machine açıkça tanımlı mı (Processing, FinalizePending, Captured, Failed, Expired)?
• Terminal statüler geri dönüşsüz mü?
• Payment snapshot (tutar, para birimi, sepet) immutable mı?
• PSP'den gelen kanıt (webhook, sync response) ayrı evidence tablosunda mı saklanıyor?
• State geçişleri evidence'e dayanıyor mu, yoksa varsayıma mı?

3. Güvenilirlik: retry, lease, outbox

• Hata taksonomisi tanımlı mı (BusinessDecline, Timeout, RateLimited, Infrastructure)?
• Her kategori için farklı retry politikası uygulanıyor mu?
• DB-backed job'lar lease ile mi işleniyor?
• Webhook handler lease + version token birlikte mi kullanıyor?
• State değişikliği ile event outbox pattern ile aynı transaction'da mı?
• Idempotency key API, consumer dedup ve DB uniqueness üçlüsü birlikte mi?

4. Recovery: otomasyon önce, runbook sonra

• Reconciliation sweeper aged FinalizePending / Expired kayıtları tarıyor mu?
• Orphan charge senaryosu correlation id ile çözülebiliyor mu?
• Multi-intent cart için sepet kilitleme var mı?
• Uniqueness wall manual review queue'ya yazıyor mu?
• Runbook kanıta dayalı mı (step log + PSP query + audit)?
• Heal/refund kararı refleks değil, prosedür mü?

5. Observability: payment id omurgası

• Her log, trace ve metrik payment id taşıyor mu?
• Step event log append-only ve her anlamlı adımı kapsıyor mu?
• deferred_finalize_count ve deferred_finalize_age_seconds metrikleri tanımlı mı?
• Drift count ani artışta alert üretiyor mu?
• Bir payment id ile checkout'tan terminal statüye tam yol izlenebiliyor mu?

6. Tutarlılık modeli: eventual, ölçülü, gözlemlenebilir

• 2PC yerine saga + reconciliation modeli bilinçli mi seçilmiş?
• Her saga adımının telafi eylemi tanımlı mı?
• Eventual consistency penceresi ölçülüyor ve ürün ekibiyle paylaşılıyor mu?
• 'Her an tutarlı' yanılsaması yerine 'kısa sürede tutarlı' hedefleniyor mu?

Checklist tamamlandığında sorulacak son soru:
  'Bu sistemin en kötü gününde ne olur?'
  → Cevap runbook'ta, metriklerde ve reconciliation'da yazılı olmalı.

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

❌ Checklist = feature tamamlandı demek
✓ Checklist = mimari ilkenin ölçülebilir testi

❌ Production ready = load test geçti
✓ Production ready = arıza anında doğru davranış kanıtlandı

❌ Daha fazla PSP = daha fazla karmaşıklık
✓ İyi sınırlar varsa, yeni PSP yalnızca gateway'i etkiler

Checklist bölümleri ve seri eşlemesi

Bölüm	Seri bölümleri	Temel soru
Sınırlar	9-10	Orchestrator PSP biliyor mu?
Durum & kanıt	1-4, 6	State evidence'e dayanıyor mu?
Güvenilirlik	5, 7-8, 11, 17, 20	Arıza anında ne olur?
Recovery	12-16, 19	Sürüklenme nasıl yakalanır?
Observability	18	Takılan ödeme görünür mü?
Tutarlılık	3, 16	2PC mi saga mı?

Production readiness değerlendirmesi

1. Checklist'in altı bölümünü bir tasarım incelemesinde tek tek geçin; her madde için evet/hayır/kısmen cevaplayın.
2. 'Kısmen' cevaplarını teknik borç listesine ekleyin; önceliklendirmeyi iş etkisine göre yapın.
3. En kötü gün senaryosunu (PSP 5xx, webhook gecikmesi, worker crash, orphan charge) tabletop exercise olarak çalıştırın.
4. Exercise sırasında hangi checklist maddelerinin boş kaldığını not edin — bunlar ilk iyileştirme hedefleridir.
5. Checklist'i canlı bir doküman olarak tutun; her production incident sonrası ilgili maddeyi güncelleyin.

Bu seriden aklında ne kalmalı

1. Production ödeme motoru happy path değil, arıza anı davranışıyla ölçülür.
2. Checklist, serinin 22 bölümünün ölçülebilir sentezidir — feature listesi değil.
3. Sınırlar (orchestrator ↔ gateway) kırılırsa geri kalan her şey o sızıntının üzerine inşa edilir.
4. En kötü gün sorusunun cevabı runbook'ta, metriklerde ve reconciliation'da yazılı olmalıdır.

Production ödeme motoru tasarlamak, 'charge API'si yazmak' değildir — capture ile complete arasındaki boşluğu kontrollü, gözlemlenebilir ve kurtarılabilir kılmaktır.

Son bölümde seriyi kariyer perspektifine taşıyoruz: fintech şirketleri aslında ne arıyor?