Scoring de fraude en temps réel à grande échelle

Le scoring de fraude à grande échelle exige une architecture fondamentalement différente du traitement par lots. Quand un paiement est en cours d'autorisation ou qu'un compte est en cours de création, vous disposez de millisecondes — pas de minutes — pour livrer un score de risque. Chez tracio.ai, nous traitons plus de 50 000 événements par seconde avec une latence de scoring médiane de 22ms. Cet article explique l'architecture qui rend cela possible.

Le pipeline de scoring

Chaque événement entrant traverse un pipeline en trois étapes : enrichissement des signaux, calcul de vecteur et scoring de risque. L'enrichissement des signaux rattache les données d'intelligence des appareils — l'empreinte du visiteur, les résultats de détection des bots, l'IP intelligence et le comportement historique — à l'événement brut. Le calcul de vecteur transforme ces signaux enrichis en un vecteur de caractéristiques de longueur fixe, optimisé pour notre modèle de scoring. Le scoring de risque fait passer le vecteur dans notre modèle entraîné et renvoie un score entre 0.0 et 1.0.

La décision de conception clé est que l'enrichissement et le calcul de vecteur sont séparés du scoring. Les données d'enrichissement sont pré-calculées et mises en cache. Lorsqu'un visiteur charge une page, nous calculons son profil d'appareil et le stockons dans Redis avec un TTL de 60 minutes. Lorsqu'une requête de scoring arrive — généralement déclenchée par un paiement ou une connexion —, nous récupérons le profil pré-calculé au lieu de le recalculer. Cela réduit la latence de scoring de plus de 200ms à moins de 30ms.

Stream processing avec Go

Notre couche d'ingestion est écrite en Go et utilise une architecture en fan-out. Les événements entrants arrivent via HTTP POST et sont immédiatement placés sur un channel interne. Un pool de goroutines worker lit depuis ce channel, effectue l'enrichissement et écrit les événements enrichis dans ClickHouse pour l'analytique et vers une file de scoring pour le traitement en temps réel. Le pool de fan-out se dimensionne dynamiquement en fonction de la profondeur de la file.

Nous avons choisi Go pour la couche d'ingestion en raison de ses excellentes primitives de concurrence et de son allocation mémoire prévisible. Chaque goroutine worker consomme environ 4KB d'espace de stack, ce qui nous permet d'exécuter des milliers de workers concurrents sur un seul nœud. Les pauses du garbage collector, inférieures à la milliseconde, sont essentielles pour maintenir une latence constante à haut débit.

Cache en edge et vecteurs de signaux

Pour nos clients au plus fort volume, nous déployons des modèles de scoring en edge à l'aide d'un cache de vecteurs de signaux pré-calculés. Lorsqu'un appareil est vu pour la première fois, nous calculons son vecteur de signaux complet et le stockons dans notre cache en edge (déployé sur Cloudflare Workers KV). Les requêtes de scoring ultérieures pour le même appareil récupèrent le vecteur en cache et exécutent le scoring localement en edge, atteignant une latence inférieure à 10ms.

Le modèle de scoring en edge est une version distillée de notre modèle complet — plus petit et plus rapide, mais optimisé pour les mêmes objectifs de précision. Nous ré-entraînons le modèle en edge chaque semaine et déployons les mises à jour via un déploiement progressif pour éviter les tempêtes d'invalidation de cache. Le modèle complet s'exécute côté serveur pour les cas où la confiance du modèle en edge est inférieure à un seuil configurable.

ClickHouse pour l'analytique

Tous les événements enrichis sont stockés dans ClickHouse, notre base de données analytique en colonnes. La compression et les performances de requête de ClickHouse nous permettent de stocker des milliards d'événements tout en supportant des requêtes analytiques en temps réel. Nos clients utilisent cette analytique pour comprendre les schémas de fraude, ajuster les seuils de scoring et enquêter sur des événements individuels.

Nous utilisons des vues matérialisées dans ClickHouse pour maintenir des métriques pré-agrégées : taux de fraude par pays, distribution du scoring par type d'appareil et taux de faux positifs par seuil. Ces vues matérialisées se mettent à jour en temps réel à mesure que les événements arrivent, fournissant des métriques prêtes pour les tableaux de bord sans requêtes d'agrégation coûteuses.

Enseignements tirés

Construire un système de scoring en temps réel nous a appris plusieurs leçons. Premièrement, le pré-calcul est l'optimisation la plus importante — tout travail que vous pouvez effectuer avant l'arrivée de la requête de scoring est un travail qui ne pèse pas sur votre budget de latence. Deuxièmement, le modèle de concurrence de Go est bien adapté au traitement d'événements à haut débit, mais vous devez faire preuve de discipline dans l'allocation mémoire pour éviter la pression sur le GC. Troisièmement, le déploiement en edge est transformateur pour la latence, mais exige une gestion soigneuse des modèles pour éviter les prédictions obsolètes.