Een realtime fraude-analysepijplijn bouwen

Het verwerken van 50.000 fingerprint-events per seconde, elk verrijken met smart signals en een risicoscore teruggeven in minder dan 10 milliseconden vereist een zorgvuldig ontworpen streaming-architectuur. Dit artikel loopt door onze pijplijn van ingestie tot beslissing.

Ingestielaag

Events komen binnen als HTTPS POST-verzoeken van onze JavaScript-agent die in de browsers van bezoekers draait. Elk event bevat de versleutelde signaal-payload — doorgaans 8-12 KB aan gecomprimeerde data die 130+ browsersignalen dekt. Onze edge servers beëindigen TLS, valideren de request-handtekening en sturen de payload door naar de verwerkingspijplijn.

We gebruiken een multi-region-deployment waarbij edge servers samen met de CDN-nodes van onze klanten worden geplaatst. Zo blijft de netwerk-round-trip onder de 20 ms voor 95% van de verzoeken wereldwijd. De edge servers zijn stateless Go-services die achter een load balancer draaien en horizontaal schalen op basis van het aantal verzoeken.

Signaalextractie

De eerste verwerkingsfase ontsleutelt en parseert de signaal-payload. Elk signaal wordt geëxtraheerd, gevalideerd en getypeerd. Canvas-hashes worden gecontroleerd tegen bekende onmogelijke waarden (die duiden op canvas-blokkering of spoofing). WebGL-parameters worden gekruisvalideerd op consistentie. Navigator-eigenschappen worden gecontroleerd tegen bekende geldige combinaties.

Deze fase voert ook signaalnormalisatie uit. User-agent-strings worden geparseerd tot gestructureerde componenten (browser, versie, OS, apparaat). Schermafmetingen worden genormaliseerd om rekening te houden met DPI-schaling. Tijdzone-offsets worden gevalideerd tegen de IP-geolocatiegegevens.

Smart Signals-verrijking

De geëxtraheerde signalen worden vervolgens verrijkt met Smart Signals-analyse — onze server-side intelligentielaag. Dit omvat incognito-detectie (signaalpatronen vergelijken met bekende signaturen van privé browsen), VPN-detectie (IP-data kruisverwijzen met tijdzone- en locale-signalen), detectie van browser-tampering (inconsistenties identificeren die wijzen op signaal-spoofing) en detectie van virtuele machines (hardwareprofielen herkennen die geassocieerd zijn met VMware, VirtualBox en cloud-VM's).

Elk smart signal wordt onafhankelijk berekend en produceert zowel een booleaans resultaat als een betrouwbaarheidsscore. De verrijkingsfase voegt 24 aanvullende signalen toe aan elk event en biedt zo een uitgebreide dreigingsbeoordeling die verder gaat dan wat client-side verzameling alleen kan bereiken.

Risicoscoring-engine

Het verrijkte event wordt doorgegeven aan onze risicoscoring-engine — een gradient-boosted decision tree-model getraind op miljoenen gelabelde events. Het model houdt rekening met alle 130+ ruwe signalen, 24 smart signals en verschillende afgeleide features: velocity-metrieken (hoeveel events van dit apparaat in de laatste 5 minuten, 1 uur en 24 uur), historische gedragspatronen en netwerkreputatiescores.

Het model geeft een risicoscore tussen 0 en 100, samen met de belangrijkste bijdragende factoren. Een score van 85 kan bijvoorbeeld vergezeld gaan van factoren als "VPN gedetecteerd", "incognitomodus" en "hoge velocity — 47 events in 5 minuten". Deze uitlegbaarheid is cruciaal voor fraude-analisten die moeten begrijpen waarom een bepaald event is gemarkeerd.

Opslag- en querylaag

Alle events worden opgeslagen in ClickHouse — een kolomgeoriënteerde database geoptimaliseerd voor analytische queries over grote datasets. ClickHouse verwerkt ons schrijfvolume (50K events/seconde) zonder moeite, en de kolomgeoriënteerde opslag maakt analytische queries van minder dan een seconde over miljarden rijen mogelijk.

We gebruiken een meerlaagse retentiestrategie. Hete data (laatste 7 dagen) wordt opgeslagen op NVMe-SSD's voor query-responstijden onder de 100 ms. Warme data (7-90 dagen) staat op standaard-SSD's. Koude data (90+ dagen) wordt gecomprimeerd en verplaatst naar object storage, opvraagbaar maar met hogere latentie.

Kafka als ruggengraat

Apache Kafka bindt de pijplijn samen. Elke fase leest van en schrijft naar Kafka-topics. De ingestielaag schrijft ruwe events. De signaalextractiefase leest ruwe events en schrijft geëxtraheerde events. De Smart Signals-verrijkingsfase leest geëxtraheerde events en schrijft verrijkte events. De risicoscoring-engine leest verrijkte events en schrijft gescoorde events.

Deze architectuur biedt verschillende voordelen: fasen kunnen onafhankelijk worden geschaald, storingen in één fase beïnvloeden andere niet, en we kunnen events opnieuw door elke fase afspelen voor debugging of herverwerking. De consumer groups van Kafka maken parallelle verwerking binnen elke fase mogelijk, en de exactly-once-semantiek zorgt ervoor dat geen enkel event tweemaal wordt verwerkt of verloren gaat.

Latentiebudget

Ons end-to-end latentiedoel is 10 ms vanaf het moment dat de verrijkte signaal-payload bij de verwerkingspijplijn aankomt tot het moment dat de risicoscore wordt teruggegeven. Zo is het budget verdeeld: signaalextractie kost 1-2 ms, Smart Signals-verrijking kost 3-4 ms, risicoscoring kost 2-3 ms, en serialisatie en respons kost 1-2 ms. De Kafka-hop tussen fasen voegt minder dan 1 ms toe in onze co-located deployment.

Dit budget consistent halen bij 50K events/seconde vereist zorgvuldige optimalisatie in elke fase. We gebruiken vooraf gealloceerde memory pools, zero-copy-serialisatie en gebatchte ClickHouse-schrijfbewerkingen. Het risicoscoring-model is gecompileerd naar native code met ONNX Runtime, waardoor de overhead van de Python-interpreter wegvalt.

Mark besteedde twee weken aan het profileren van de pijplijn voordat hij het knelpunt vond in onze gedistribueerde lookup-laag — één enkele mutex serialiseerde lookups over alle goroutines. Na de overstap naar een sharded lock-ontwerp daalde p99 van 48 ms naar 9 ms. Soms is de oplossing gênant eenvoudig zodra je hem gevonden hebt.