Fintech Altyapısı: 50M İşlem, %99.9 Uptime

İlk çeyrekte 10 milyon işlemi aştığımızda, erken dönemde aldığımız mimari kararların bizi ileriye taşıyıp taşımayacağını ya da birer engele dönüşüp dönüşmeyeceğini biliyorduk. Bu yazı, 50 milyonu aşkın işlemi %99.9 uptime ile kaldıran bir fintech altyapısını nasıl inşa ettiğimizin ve bu süreçte öğrendiklerimizin hikayesidir.

Yaptığımız İlk Hatalar

Fintech altyapısı kuran her mühendislik ekibi hata yapar. Bizimkiler erken geldi ve öğreticiydi.

Monolitik bir mimariyle başladık — ödeme işleme, muhasebe yönetimi, kullanıcı kimlik doğrulama ve bildirim teslimatını tek bir büyük serviste topladık. Aylık 100.000 işlemde gayet iyi çalıştı. 1 milyonda çatlaklar belirmeye başladı: tek bir yavaş veritabanı sorgusu tüm ödeme akışını bozabiliyordu. Bildirim trafiğindeki ani artışlar ödeme onaylarını engelleyebiliyordu.

İlk ders: fintech'te her alt sistem kritik öneme sahiptir ve hata modlarını paylaşamazlar.

Mimari Dönüşüm: Olay Güdümlü Mikroservisler

Olay güdümlü mikroservis mimarisini temel alarak yeniden inşa ettik. Her domain — ödemeler, muhasebe, uyumluluk, bildirimler — bir olay veri yolu üzerinden iletişim kuran bağımsız bir servise dönüştü. Apache Kafka'yı omurga olarak seçtik; popüler olduğu için değil, belirli özellikleri nedeniyle: partition içinde garantili mesaj sıralaması, kalıcı log depolama ve mutabakat için olayları yeniden oynatabilme.

Temel tasarım kararları:

Ödeme İşleme Servisi: Durumsuz, yatay ölçeklenebilir. Her örnek bir işlemi başlangıçtan yetkilendirmeye kadar yönetir. Paylaşılan bellek içi durum yok. Bir örnek işlem ortasında çökerse, başka bir örnek son kalıcı kontrol noktasından devam eder.

Muhasebe Servisi: Tüm finansal bakiyelerin tek doğru kaynağı. Yalnızca ekleme yapılabilen (append-only) bir muhasebe defteri uyguladık — her alacak ve borç kaydı yeni bir satırdır, güncelleme asla yapılmaz. Bu değişmezlik pazarlık konusu değildi: tam denetim izi sağlar ve mutabakatı basitleştirir.

Uyumluluk Servisi: AML ve dolandırıcılık kontrolleri için asenkron işleme. Tanımlanmış eşiklerin altındaki düşük riskli işlemlerde uyumluluk kontrolleri yetkilendirme sonrası çalışır. Yüksek riskli işlemlerde ise eş zamanlı olarak engeller. Bu kademeli yaklaşım ortalama işlem gecikmesini 800ms'den 120ms'ye indirdi.

Veritabanı Stratejisi: Okuma ve Yazma Yollarını Ayırma

En etkili kararlardan biri okuma ve yazma yollarını tamamen ayırmaktı.

Tüm yazma işlemleri, bir yedek sunucuya senkron çoğaltmayla birlikte birincil PostgreSQL kümesinden geçer. Tüm veritabanı işlemlerinin %80'ini oluşturan okumalar ise 50ms çoğaltma gecikmesi toleransıyla okuma replikalarından yapılır.

İşlem aramaları ve bakiye sorguları için 30 saniyelik TTL'e sahip bir Redis önbellekleme katmanı ekledik. Bu tek başına veritabanı okuma yükünü %65 azalttı.

Ayrıca veri katmanında olay kaynakçılığı uyguladık: ödeme yaşam döngüsündeki her durum değişikliği değişmez bir olay olarak depolanır. Herhangi bir işlemin mevcut durumu, olay geçmişi yeniden oynatılarak yeniden oluşturulabilir. Bu, müşteri anlaşmazlıklarının ve düzenleyici soruşturmaların hata ayıklamasında paha biçilmez oldu.

50 Katlık Trafik Artışlarını Yönetmek

Fintech platformları öngörülebilir ve öngörülemeyen trafik artışları yaşar. Maaş ödeme günleri, çeyrek sonu ödemeleri ve promosyon kampanyaları dakikalar içinde normal trafiğin 50 katını üretebilir.

Yaklaşımımız ön ölçeklendirme ile reaktif otomatik ölçeklendirmeyi birleştirdi:

• Ön ölçeklendirme: Geçmiş işlem örüntülerini analiz edip beklenen tepe noktalarından 20 dakika önce ölçeklendiriyoruz
• Reaktif otomatik ölçeklendirme: Kubernetes HPA, özel metrikler üzerinde tetiklenir — yalnızca CPU değil, işlem kuyruğu derinliği ve p95 işleme gecikmesi de
• Devre kesiciler: Her harici API çağrısının (kart ağları, bankacılık ortakları) bir devre kesicisi var. Bağımlılık bozulursa, iş parçacıklarını tutmak yerine hızlıca başarısız olup yeniden deneme için kuyruğa alıyoruz

Sonuç: son büyük trafik olayımızda (büyük bir e-ticaret entegrasyonunun devreye girmesi) 47 katlık trafik artışı yaşandı. Sıfır düşen işlem gördük.

%99.9 Uptime Gerçeği

Uptime hedefleri yazmak kolaydır. Bunlara ulaşmak iki alanda amansız disiplin gerektirir: dağıtım uygulamaları ve bağımlılık yönetimi.

Dağıtımlar için canary sürümlerle mavi-yeşil kullanıyoruz. Yeni sürümler tam dağıtımdan önce 30 dakika boyunca trafiğin %5'ini alır. %20'nin üzerinde herhangi bir p99 gecikme artışı otomatik geri almayı tetikler.

Bağımlılıklar için her harici sistemin çökeceğini varsayıyoruz. Kart ağı API'leri, bankacılık ortağı bağlantıları, KYC sağlayıcılar — hepsi yerel yedek kuyruğun arkasında yer alır. Bir bağımlılık çöktüğünde işlemler yerel olarak kuyruğa girer ve bağımlılık kurtardıkça üstel geri çekilme ile işleriz. Kullanıcılar hata değil, hafif bir işlem gecikmesi görür.

Farklı Yapardık

Sıfırdan başlasaydık üç şeyi daha erken yapardık:

1. Dağıtık izlemeyi başından uygulayın. OpenTelemetry'yi altı ay sonra ekledik ve işlem yaşam döngüsünü yalnızca loglardan yeniden oluşturmak bize yüzlerce mühendislik saatine mal oldu.

2. SLO'ları kod yazmadan önce tanımlayın. %99.9 uptime hedefimiz bir iş gereksiniminden geldi. Teknik uygulama, ilk satırdan itibaren bu hedef etrafında tasarlanmış olmalıydı.

3. Kaos mühendisliğine daha erken yatırım yapın. İlk GameDay'imizi dördüncü ayda yaptık. O zamana kadar üretimde tasarlamadığımız iki hata modeliyle zaten karşılaşmıştık.

Bugünün Rakamları

• 50M+ işlenmiş işlem
• 18 ay boyunca %99.9 uptime
• 120ms ortalama işlem gecikmesi (p50)
• Tepe yükünde 380ms p99 gecikme
• Sıfır veri kaybı olayı

Fintech'te önem taşıyan mimari kararlar gösterişli değildir. Doğru yerlerde kullanılabilirlik yerine tutarlılık, her yerde hata varsayımı ve düzenleyicilerin ve müşterilerin tamamen güvenebileceği bir denetim izini sürdürmekle ilgilidir.