Fintech Şirketleri Aslında Ne Arıyor? (Fintech Sirketleri Aslinda Ne Ariyor)

22 bölümlük bu seri, production ödeme motorunun teknik mimarisini baştan sona ele aldı. Son bölüm farklı bir soruya cevap veriyor: bu bilgiyi kariyerinizde nasıl konumlandırırsınız? Fintech şirketleri mülakatlarda gerçekten ne arıyor?

Kısa cevap: bir PSP'nin SDK'sını entegre etmeyi bilmek değil. SDK entegrasyonu öğrenilebilir bir beceridir; bir haftada dokümantasyon okuyarak yapılabilir. Şirketlerin aradığı şey, SDK'nın altındaki düşünce modelidir: bir ödeme başarısız olduğunda ne olur, webhook geç geldiğinde ne olur, aynı mesaj iki kez geldiğinde ne olur?

Mülakatta aranan
  ❌ 'Stripe SDK kullandım'
  ✓ 'Exactly-once yok; effectively-once defense in depth ile inşa ettim'
  ✓ 'Orphan charge senaryosunu correlation id ile çözdüm'
  ✓ 'Reconciliation worker ile drift'i ölçülebilir kıldım'

Kavramlar ilk geçtiği yerde

📦 Failure Thinking
Her mutlu yol senaryosunun yanına 'peki ya bu adım başarısız olursa' sorusunu koyma alışkanlığı.

📦 Evidence-Driven Engineering
Kararların varsayıma değil, kanıt tablosuna (step log, PSP query, audit) dayanması.

📦 Operational Maturity
Sistemin sadece çalışması değil, bozulduğunda görünür ve kurtarılabilir olması.

📦 Transferable Pattern
Belirli bir PSP'ye değil, dağıtık ödeme problemine uygulanabilir mimari kalıp.

Fintech mülakatlarında 'hangi SDK kullandın' sorusu, 'hangi soruları sordun ve hangi trade-off'ları bilinçli seçtin' sorusunun kılıfıdır.

SDK entegrasyonu yetkinlik değil, başlangıç noktası

Bir PSP SDK'sını entegre etmek, ödeme sistemlerinde en görünür ama en az ayırt edici beceridir. Her fintech şirketi bunu bir noktada yapar; mülakat farkını yaratan, entegrasyonun ötesinde ne düşündüğünüzdür.

Seviye 1: SDK entegrasyonu
  → charge API çalışıyor, webhook alınıyor

Seviye 2: Failure handling
  → timeout vs decline ayrımı, retry taksonomisi

Seviye 3: Distributed thinking
  → idempotency, lease, outbox, reconciliation

Seviye 4: Operational ownership
  → observability, runbook, worst-day senaryosu

Şirketler Seviye 1'i iş ilanında yazar; Seviye 3-4'ü mülakatta arar. Bu seri, Seviye 2'den 4'e köprü kurar.

Mülakatta ayırt eden beş düşünce kalıbı

1. Failure taxonomy: 'Bir ödeme başarısız oldu' demek yerine, business decline mı, timeout mu, 429 mu, 5xx mi — ve her biri için farklı aksiyon. Bu serinin 11-12. bölümlerinin özü.

2. Idempotency beyond API: Idempotency key yalnızca API isteğini korumaz; webhook consumer, async worker ve DB constraint birlikte çalışmalıdır. Exactly-once vaat etmezsiniz; effectively-once inşa edersiniz.

3. Reconciliation as design, not afterthought: Mutabakat 'sonradan eklenen bir cron job' değil; sistemin dürüstlüğünün ölçüsüdür. Drift count metriği, sistemin ne kadar iyi çalıştığını değil, ne kadar dürüst olduğunu gösterir.

4. Evidence over assumption: Orphan charge'ta 'hemen refund et' refleksi değil; correlation id → step log → PSP query → karar. Panik anında en güvenli aksiyon, kanıt bulana kadar beklemektir.

5. Boundaries that survive PSP swap: Orchestrator'ın PSP SDK'sını hiç görmemesi; semantic event'lerin downstream'e ham payload olarak değil iş diliyle ulaşması. Üç yıl sonra provider değiştirdiğinizde orchestrator kodu değişmemeli.

CV ve mülakat diline çevirmek

Seri kavramı	CV/mülakat dili
Provider abstraction	'Built PSP-agnostic payment orchestration layer'
Failure taxonomy	'Designed retry policies differentiated by failure category'
Idempotency + dedup + uniqueness	'Achieved effectively-once charge outcomes via defense in depth'
Reconciliation worker	'Built automated drift detection reducing manual payment review by X%'
Step event log + payment id correlation	'Implemented payment lifecycle observability enabling sub-minute incident triage'
Evidence-driven runbook	'Authored operational runbooks for orphan charge and duplicate finalize scenarios'

Rakamlar (X%) gerçek olmalıdır; bu seri size kavramları verir, rakamları siz üretirsiniz.

Junior vs senior: aranan fark

Junior pozisyonlarda SDK entegrasyonu ve temel API bilgisi yeterli olabilir. Senior ve staff pozisyonlarda sorulan soru değişir: 'Bu sistemi production'a aldığınızda en kötü gün senaryosu ne, ve ona hazır mısınız?' Cevap, bu serinin 21. bölümündeki checklist'tir.

Junior mülakat sorusu
  → 'Webhook nasıl alırsın?'

Senior mülakat sorusu
  → 'Aynı webhook iki kez gelirse ne olur?'
  → 'PSP Captured diyor, local Expired — ne yaparsın?'
  → 'Exactly-once garanti eder misin?'

Son sorunun cevabı 'hayır, effectively-once inşa ederim' ise, bu seriyi anlamışsınız demektir.

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

❌ Fintech = payments SDK bilgisi
✓ Fintech = dağıtık sistem düşüncesi + ödeme domain bilgisi

❌ Daha fazla PSP deneyimi = daha güçlü aday
✓ Transferable pattern bilgisi = daha güçlü aday

❌ Bu seri sadece backend mühendisleri için
✓ Operasyonel olgunluk, platform ve SRE rollerinde de aranan beceridir

Ne aranmaz vs ne aranır

Aranmaz	Aranır
Belirli PSP sertifikası	Failure/reconciliation düşüncesi
'Charge API yazdım'	'Worst-day senaryosuna hazırım'
Exactly-once iddiası	Effectively-once kanıtı
Ham webhook pass-through	Semantic event + çeviri katmanı

Kariyer konumlandırma kontrol listesi

1. CV'nizde en az bir 'failure handling' ve bir 'reconciliation/drift' maddesi var mı?
2. Mülakatta 'exactly-once' sorusuna effectively-once cevabı verebiliyor musunuz?
3. Bir orphan charge veya duplicate finalize senaryosunu kanıt tabanlı anlatabiliyor musunuz?
4. Provider abstraction'ı 'interface tanımladım' değil, 'orchestrator PSP bilmiyor' olarak anlatıyor musunuz?
5. Bu serinin checklist'ini (bölüm 21) kendi projelerinize uygulayıp boşlukları tespit ettiniz mi?

Bu seriden kariyer perspektifinde ne kalmalı

1. Fintech şirketleri SDK entegrasyonunu değil, failure/reconciliation/idempotency düşüncesini arar.
2. Bu serinin 22 bölümü, mülakatta ayırt eden beş düşünce kalıbının tamamını kapsar.
3. 'Exactly-once garanti eder misin' sorusunun doğru cevabı 'hayır, effectively-once inşa ederim'dir.
4. Production readiness, worst-day sorusuna cevap verebilmektir — checklist bunun ölçüsüdür.

Fintech mülakatında fark yaratan cümle 'Stripe SDK kullandım' değil; 'orphan charge senaryosunu correlation id ve evidence-driven runbook ile çözdüm'dür.

Bu, Distributed Payment Engine serisinin son bölümüdür. 22 bölüm boyunca savunduğumuz tek gerçek değişmedi: dağıtık bir ödeme sistemi mükemmelliği değil, kontrollü ve gözlemlenebilir tutarsızlığı hedefler — ve bu düşünce, en değerli kariyer varlığınızdır.