Anlık Ödemelerde Gerçek Zamanlı Dolandırıcılık Kararı

Problem

Orta ölçekli bir Avrupa perakende bankası anlık ödeme şemasına katılıyor. Dolandırıcılık kuralları bugün gece toplu işinde çalışıyor. Yeni düzende, 10 saniyelik ödeme penceresinin 150 ms’si dolandırıcılık kararına ayrılıyor. Yük ortalama saniyede 300, tepede 3.000 ödeme. Mainframe’e yalnızca IBM MQ ile erişilebiliyor ve değiştirilemiyor. Her karar açıklanabilir olmalı ve yedi yıl boyunca yeniden üretilebilmeli. İki aktif veri merkezi şart; kart ve açık bankacılık da sonradan eklenebilmeli.

Yaklaşım

İki istek birbirine ters düşüyor: dar bir gecikme bütçesi ve yıllar sonra tekrar oynatılabilen kararlar. Tasarım özellikleri önceden hesaplıyor, kararı tek süreçte veriyor ve her girdiyi saklıyor. Flink 90 günlük davranış özelliklerini hesaplayıp Valkey’e yazıyor. Karar servisi tek bir özellik vektörünü okuyor, ardından Drools kurallarını ve ONNX modelini aynı JVM’de çalıştırıyor. Her karar; özellik vektörü, kural seti sürümü, model özeti ve imaj özetiyle bir anlık görüntü (snapshot) olarak kaydediliyor.

Mimari

• Mainframe köprüsü: IBM MQ için Kafka Connect kaynak ve hedef konnektörleri. Platform mainframe’i hiç çağırmıyor.
• Omurga: iki veri merkezine yayılmış tek Kafka kümesi, üçüncü sitede KRaft tanığı. Şemalar, Apicurio Registry’de Avro sözleşmesi olarak duruyor.
• Özellikler ve karar: Flink, Valkey ve Drools ile ONNX Runtime çalıştıran bir Quarkus karar servisi.
• Kanıt ve öğrenme: snapshot’lar Object Lock’lu nesne depolama üzerinde Apache Iceberg’e gidiyor. MLflow modelleri izliyor. Analist sonuçları eğitim etiketi olarak geri dönüyor.

Veri akışı: MQ’da ödeme isteği, Kafka, karar; ardından karar ve snapshot tek Kafka işleminde yazılıyor ve yanıt MQ’dan dönüyor.

Kararlar ve ödünleşimler

• Model, karar sürecinin içinde. Kata, ayrı bir model servisi için 150 ms’lik bütçeden 20–40 ms tahmin ediyor. JVM içinde ONNX Runtime yaklaşık 2 ms’de skorluyor. Operasyonel esnekliği p99 gecikme için feda ettim. Terfi ve geri alma yine bir işaretçi değişikliği; iki model de bellekte yüklü. Bütçe bu kadar dar olmasaydı ayrı bir model servisi daha esnek seçim olurdu.
• Özellikler saklanıyor, yeniden hesaplanmıyor. Her snapshot özellik vektörünü, kural seti sürümünü, model özetini ve imaj özetini tutuyor. Bir kararı tekrar oynatmak, aynı imajı aynı vektörle çalıştırmak demek. Yeniden hesaplamak sonradan gelen veriyi kullanır ve sonucu değiştirir. Aynı snapshot’lar eğitim setine dönüşüyor; eğitim ve servis aynı özellikleri görüyor. Bedeli arşiv boyutu: yedi yılda yaklaşık 45 TB tahmin edildi.
• MirrorMaker 2 ile iki küme yerine yayılmış tek Kafka kümesi. İdempotentlik, ilk yazanın kazandığı tek bir sıkıştırılmış karar topic’ine dayanıyor. Bu kural iki kümede tanımlanamaz. Karar ortasında bir veri merkezi düşerse diğer taraf skorlamadan önce topic’e bakıyor. Bedeli, KRaft tanığı için iki merkeze de 10 ms’den yakın üçüncü bir site.
• Senkron yolda doğrudan MQ değil, Kafka. Kafka tek log’dan tekrar oynatma, Flink özellik işlerine dağıtım ve denetim izi veriyor. MQ’dan doğrudan okumak bu üçünü ayrı ayrı kurmak demek. Bedeli poll ve kuyruk beklemesi: yaklaşık 8 ms, tahmini 40 ms’lik p99 içinde kalıyor.
• Sıralı bozulma. Özellik yoksa yalnızca kurallar; bu, fallback oranı olarak raporlanıyor. Kural yoksa temkinli eşikle model. İkisi de yoksa incelemeye gönderme. Mainframe tarafında zaman aşımı da inceleme demek; kör onay asla. Bedeli, bir olay sırasında daha çok bekletilen ödeme. En büyük risk yanlış pozitif olduğu için fallback oranı panoda duruyor.
• Challenger aynı süreçte. Challenger her ödemeyi gölge modda skorluyor; sonucu yalnızca kaydediliyor. Terfi, dört göz onayıyla champion işaretçisini taşımak. Geri alma onu geri taşımak; hiçbir şey yeniden başlamıyor. Bedeli, her karar pod’unda bellekte iki model.

Yeniden ele alacaklarım

• Mainframe zaman aşımı varsayılanı. Yanıt geciktiğinde mainframe bekletiyor mu, onaylıyor mu? Bozulma tasarımı bu cevaba bağlı.
• Üçüncü site. İki merkeze de 10 ms’den yakın bir site yoksa topoloji MirrorMaker 2 ile iki kümeye döner. O zaman “ilk yazan kazanır” kuralı tasarlandığı gibi çalışmaz.
• Kart token’ları. Kart platformu gerçekten token gönderebiliyor mu, yoksa kart numarası görünecek mi? PCI kapsamı buna bağlı.
• Özellik sayısı ve pencereler. 40 özellik ve 90 gün varsaydım. Gerçek sayılar Valkey ve Flink boyutunu belirler.

Sonuç notları (tasarım varsayımları, ölçüm değil)

Bu bir tasarım çalışmasıdır, üretim sistemi değildir. Çıktı: dört sayfalık diyagram seti, tek sayfalık beyaz tahta sürümü ve 14 sayfalık Türkçe PDF. PDF’te varsayımlar, bileşen gerekçeleri, lisanslar, kapasite hesapları ve açık sorular var. Gecikme bütçesi (150 ms’ye karşı p99’da yaklaşık 40 ms) ölçüm değil, tasarım tahminidir.

Kaynaklar

• Mimari PDF (Türkçe, 14 sayfa).
• draw.io diyagramları (İngilizce etiketler): dört sayfalık set ve 30 dakikalık tek sayfa sürüm.