Fraud Scoring Real-Time dalam Skala Besar

Fraud scoring dalam skala besar membutuhkan arsitektur yang secara fundamental berbeda dari batch processing. Ketika sebuah pembayaran sedang diotorisasi atau sebuah akun sedang dibuat, Anda hanya punya milidetik — bukan menit — untuk memberikan skor risiko. Di tracio.ai, kami memproses lebih dari 50.000 event per detik dengan latensi scoring median 22ms. Artikel ini menjelaskan arsitektur yang memungkinkan hal tersebut.

Pipeline Scoring

Setiap event yang masuk melewati pipeline tiga tahap: signal enrichment, komputasi vektor, dan risk scoring. Signal enrichment melampirkan data device intelligence — fingerprint pengunjung, hasil bot detection, IP intelligence, dan perilaku historis — ke event mentah. Komputasi vektor mengubah sinyal yang sudah diperkaya ini menjadi feature vector dengan panjang tetap yang dioptimalkan untuk model scoring kami. Risk scoring menjalankan vektor melalui model terlatih kami dan mengembalikan skor antara 0.0 dan 1.0.

Keputusan desain utamanya adalah bahwa enrichment dan komputasi vektor dipisahkan dari scoring. Data enrichment dikomputasi lebih awal dan disimpan dalam cache. Ketika seorang pengunjung memuat sebuah halaman, kami mengomputasi profil perangkatnya dan menyimpannya di Redis dengan TTL 60 menit. Ketika permintaan scoring tiba — biasanya dipicu oleh sebuah pembayaran atau login — kami mengambil profil yang sudah dikomputasi alih-alih menghitungnya ulang. Hal ini menurunkan latensi scoring dari 200ms+ menjadi di bawah 30ms.

Stream Processing dengan Go

Lapisan ingestion kami ditulis dalam Go dan menggunakan arsitektur fan-out. Event yang masuk tiba melalui HTTP POST dan langsung ditempatkan pada sebuah channel internal. Sebuah pool worker goroutine membaca dari channel ini, melakukan enrichment, dan menulis event yang sudah diperkaya ke ClickHouse untuk analitik serta ke antrean scoring untuk pemrosesan real-time. Pool fan-out menyesuaikan skala secara dinamis berdasarkan kedalaman antrean.

Kami memilih Go untuk lapisan ingestion karena primitif konkurensinya yang sangat baik dan alokasi memori yang dapat diprediksi. Setiap worker goroutine mengonsumsi sekitar 4KB ruang stack, memungkinkan kami menjalankan ribuan worker secara bersamaan pada satu node. Jeda garbage collector yang di bawah satu milidetik sangat penting untuk menjaga latensi tetap konsisten pada throughput tinggi.

Edge Caching dan Vektor Sinyal

Untuk pelanggan bervolume tertinggi, kami menerapkan model scoring di edge menggunakan cache vektor sinyal yang telah dikomputasi. Ketika sebuah perangkat pertama kali terlihat, kami mengomputasi vektor sinyal lengkapnya dan menyimpannya di edge cache kami (yang berjalan pada Cloudflare Workers KV). Permintaan scoring berikutnya untuk perangkat yang sama akan mengambil vektor yang tersimpan dan menjalankan scoring secara lokal di edge, mencapai latensi di bawah 10ms.

Model edge scoring adalah versi hasil distilasi dari model penuh kami — lebih kecil dan lebih cepat, tetapi dioptimalkan untuk target akurasi yang sama. Kami melatih ulang model edge setiap minggu dan menerapkan pembaruan melalui rolling deployment untuk menghindari badai invalidasi cache. Model penuh berjalan di sisi server untuk kasus-kasus di mana confidence model edge berada di bawah ambang batas yang dapat dikonfigurasi.

ClickHouse untuk Analitik

Semua event yang sudah diperkaya disimpan di ClickHouse, basis data analitik kolumnar kami. Kompresi dan performa kueri ClickHouse memungkinkan kami menyimpan miliaran event sekaligus mendukung kueri analitik real-time. Pelanggan kami menggunakan analitik ini untuk memahami pola fraud, menyetel ambang scoring, dan menyelidiki event individual.

Kami menggunakan materialized view di ClickHouse untuk memelihara metrik yang sudah diagregasi sebelumnya: tingkat fraud per negara, distribusi scoring per tipe perangkat, dan tingkat false positive per ambang batas. Materialized view ini diperbarui secara real-time seiring event yang masuk, menyediakan metrik yang siap ditampilkan di dashboard tanpa kueri agregasi yang mahal.

Pelajaran yang Dipetik

Membangun sistem scoring real-time mengajarkan kami beberapa pelajaran. Pertama, komputasi awal adalah optimasi yang paling penting — pekerjaan apa pun yang bisa Anda lakukan sebelum permintaan scoring tiba adalah pekerjaan yang tidak membebani anggaran latensi Anda. Kedua, model konkurensi Go sangat cocok untuk pemrosesan event bervolume tinggi, tetapi Anda harus disiplin dalam alokasi memori untuk menghindari tekanan GC. Ketiga, penerapan di edge bersifat transformatif untuk latensi tetapi membutuhkan manajemen model yang cermat agar prediksi tidak menjadi usang.