Gerçek Zamanlı Dolandırıcılık Tespiti Mimarisi (12K TPS): 2026 İçin Tam Referans Yığın
Saniyede 12K işlem için gerçek zamanlı dolandırıcılık tespiti referans mimarisi: Go ile event-driven tasarım, PostgreSQL partitioning, ML model servisi ve ölçekte 50ms altı gecikmeyi tutan kararlar.
Aşağıdaki referans mimari, her işlem onaylanmadan önce puanlanması gereken bir fintech ekibinin ihtiyaç duyduğu sistem şeklidir. Yoğun saatte saniyede 12.000 işlem ile hedef, sıfır kayıp ile uçtan uca 50ms altı gecikmedir. Bu tip bir inşayı kapsamlandırırken kullandığımız örüntü.
Mimari üç katmandan oluşuyor. Veri alma katmanı işlem olaylarını AWS ALB arkasındaki bir Go servisi üzerinden alıyor. Go'yu Node.js yerine seçtik çünkü goroutine'ler bu ölçekte I/O-bound iş için 10 kat daha iyi eşzamanlılık sağladı. Her olay hemen merchant ID'ye göre bölümlanmış bir Kafka topic'ine yazılıyor. Merchant başına sıralama garantisi verirken merchantlar arası paralel işleme izin veriyor.
Puanlama katmanı iki aşamalı bir pipeline çalıştırıyor. Birinci aşama deterministik kurallar uyguluyor: hız kontrolleri (aynı kart 60 saniyede 5 kez kullanıldı), coğrafi imkansızlık (İstanbul'da işlem, 10 dakika sonra Londra'da), ve tutar anomalileri. Bu kurallar tek başlarına dolandırıcılığın %40'ını neredeyse sıfır gecikmeyle yakalıyor çünkü sadece Redis cluster'a karşı bellekte arama gerektiriyor.
İkinci aşama ML modelini çalıştırıyor. LightGBM modelini Python Flask wrapper değil, özel bir Go servisi üzerinden sunuyoruz. Model 18 aylık etiketlenmiş işlem verisi üzerinde eğitildi (2.3M örnek, %0.8 dolandırıcılık oranı). Özellik mühendisliği zor kısımdı: işlem başına 47 özellik hesaplıyoruz: hareketli ortalamalar, gün içi zaman kalıpları, merchant kategori risk skorları ve cihaz parmak izi benzerliği dahil. Model çıkarımı işlem başına 8-12ms sürüyor.
PostgreSQL kalıcılık katmanını yönetiyor, ama çoğu kişinin kullandığı şekilde değil. İşlemler tablosunu tarihe göre (aylık) bölümlüyor, risk skoru aralığına göre alt bölümleme yapıyoruz. Bu sıcak sorguları hızlı tutuyor: son yüksek riskli işlemleri araştırmak terabyte'ları taramak yerine küçük bir bölüme vuruyor. Ayrıca zaman damgası sütunlarında BRIN indeksleri kullanıyoruz. Zaman serisi verileri için B-tree indekslerinden 100 kat daha küçükler.
Anahtar mühendislik kararı sistemi güçlü tutarlılık yerine nihai tutarlılık olarak tasarlamaktı. İşlem gerçek zamanlı skora göre 50ms içinde onaylanıyor veya işaretleniyor. Ama tam denetim izi, merchant risk profili güncellemesi ve uyum raporu üretimi Kafka tüketicileri üzerinden asenkron olarak gerçekleşiyor. Gecikme hedefini ulaştırılabilir kılan bu ayırma.
Bu mimari tune edildiğinde mümkün kılanlar: 30'lu milisaniyelerde p95 gecikme, %99.9 üzeri uptime hedefleri veri alma + Kafka + Go sunum tasarımıyla gerçekçi, ve ML modeli statik kuralların kaçırdığı dolandırıcılık kalıplarını yakalar. Kanonik örnek: büyük bir ücret öncesi günlerce küçük işlemlerle kart geçerliliğini test eden yavaş damlama kart testleri. Statik kurallar tek başına dolandırıcılığın anlamlı bir bölümünü kapsar, ML aşaması ise daha zor durumları açar.
Ders: ölçekte gerçek zamanlı sistemler en hızlı dili veya veritabanını seçmekle ilgili değil. Doğru veri akışını tasarlamak, sıcak yolu soğuk yoldan ayırmak ve tutarlılık ile gecikme arasında bilinçli takas yapmakla ilgili. Sıcak yoldaki her milisaniye tahmin değil, profilleme ve ölçüm yoluyla kazanıldı.
Önemli Çıkarımlar
- 01Veri alma: yük dengeleyici arkasında Go servisi, olaylar sıralama artı paralellik için merchant ID ile bölümlenmiş bir Kafka topic'ine hemen yazılıyor.
- 02Puanlama aşama 1: Redis üzerinde neredeyse sıfır gecikmede çalışan deterministik kurallar (hız, coğrafi imkansızlık, tutar anomalileri); ML çalışmadan önce dolandırıcılığın anlamlı bir bölümünü yakalıyor.
- 03Puanlama aşama 2: LightGBM, özel bir Go servisi üzerinden (Python Flask wrapper değil), her işlem için dikkatle tasarlanmış özelliklerle. Çıkarım tek haneli veya düşük çift haneli milisaniye seviyesinde.
- 04Kalıcılık: tarihe göre bölümlenmiş, risk skoru aralığına göre alt bölümlenmiş PostgreSQL, artı timestamp kolonlarında BRIN index'leri, terabyte ölçeğinde bile inceleme sorgularını hızlı tutuyor.
- 05Gecikme eventual consistency'den geliyor: puanlama ve onayla-veya-işaretle kararı senkron ve hızlı, audit trail, merchant risk profili ve uyumluluk raporları Kafka tüketicileri üzerinden asenkron çalışıyor.
Sıkça Sorulan Sorular
Veri alma katmanında neden Node.js yerine Go?
Bu ölçekte I/O-bound iş için Go'nun goroutine'leri çekirdek başına Node.js'ten çok daha iyi eşzamanlılık sağlıyor. Sıkı tail-latency bütçeli 12K TPS hedefinde bu marj önemli. Node.js daha düşük TPS'te sorun değil, özellikle yığınınızın geri kalanı JavaScript ise.
ML modelini sunmak için Python ve Flask kullanabilir miyim?
Teknik olarak evet, ama bu ölçekte modelin önünde Python web framework'ü ihmal edilemez gecikme ve eşzamanlılık yükü ekliyor. Modeli Go gibi derlenmiş bir dilden doğrudan bellek erişimiyle sunmak p95 çıkarımı gecikme bütçesi altında tutuyor.
PostgreSQL'i neden tarihe göre bölümleyip risk skoruna göre alt bölümlüyoruz?
Dolandırıcılık inceleme sorguları neredeyse her zaman 'yakın tarihli yüksek riskli işlemler'. Tarihe göre bölümleme, sorgunun terabyte taraması yerine küçük bir bölüme çarpmasını sağlıyor. Risk skoruna göre alt bölümleme, düşük riskli satırları tamamen atlamasını sağlıyor. Timestamp'lerde BRIN index'leri index boyutunu küçük tutuyor.
TPS'im çok daha düşükse tüm bunlara ihtiyacım var mı?
Hayır. Yaklaşık 500 TPS altında, daha basit bir yığın (Redis'li Node.js veya Python, tek iyi index'lenmiş PostgreSQL örneği, senkron puanlama) işletmesi daha kolay ve yeterince hızlı. Bu mimari, kanıtlanmış hacminiz, sıkı gecikme bütçeleriniz ve operasyonel karmaşıklığı haklı çıkaran dolandırıcılık kaybı rakamlarınız olduğunda içindir.
Projeniz için konuşalım
15 dakika, taahhut yok.