Bedrägeriscoring i realtid i stor skala

Bedrägeriscoring i stor skala kräver en fundamentalt annorlunda arkitektur än batchbearbetning. När en betalning auktoriseras eller ett konto skapas har du millisekunder — inte minuter — på dig att leverera ett riskscore. På tracio.ai bearbetar vi över 50 000 händelser per sekund med en median-latens för scoring på 22 ms. Den här artikeln förklarar arkitekturen som gör detta möjligt.

Scoring-pipelinen

Varje inkommande händelse går in i en pipeline i tre steg: signalberikning, vektorberäkning och riskscoring. Signalberikning kopplar data från device intelligence — besökarens fingerprint, resultat från bot-detektering, IP-intelligens och historiskt beteende — till den råa händelsen. Vektorberäkning omvandlar dessa berikade signaler till en feature-vektor med fast längd, optimerad för vår scoring-modell. Riskscoring kör vektorn genom vår tränade modell och returnerar ett score mellan 0,0 och 1,0.

Det avgörande designbeslutet är att berikning och vektorberäkning är åtskilda från scoring. Berikningsdata förberäknas och cachas. När en besökare laddar en sida beräknar vi deras enhetsprofil och lagrar den i Redis med en TTL på 60 minuter. När en scoring-förfrågan anländer — vanligtvis utlöst av en betalning eller inloggning — hämtar vi den förberäknade profilen istället för att räkna om den. Detta minskar scoring-latensen från 200 ms+ till under 30 ms.

Strömbearbetning med Go

Vårt intagslager är skrivet i Go och använder en fan-out-arkitektur. Inkommande händelser anländer via HTTP POST och placeras omedelbart på en intern kanal. En pool av worker-goroutiner läser från denna kanal, utför berikning och skriver de berikade händelserna till ClickHouse för analys och till en scoring-kö för bearbetning i realtid. Fan-out-poolen skalar dynamiskt baserat på ködjup.

Vi valde Go för intagslagret på grund av dess utmärkta primitiver för samtidighet och förutsägbara minnesallokering. Varje worker-goroutin förbrukar cirka 4 KB stackutrymme, vilket gör att vi kan köra tusentals samtidiga workers på en enda nod. Garbage collector-ns pauser under en millisekund är avgörande för att bibehålla konsekvent latens vid hög genomströmning.

Edge-cachning och signalvektorer

För våra kunder med störst volym driftsätter vi scoring-modeller vid edge med hjälp av en förberäknad cache av signalvektorer. När en enhet ses för första gången beräknar vi dess fullständiga signalvektor och lagrar den i vår edge-cache (driftsatt på Cloudflare Workers KV). Efterföljande scoring-förfrågningar för samma enhet hämtar den cachade vektorn och kör scoring lokalt vid edge, vilket ger en latens under 10 ms.

Edge-scoring-modellen är en destillerad version av vår fullständiga modell — mindre och snabbare, men optimerad för samma noggrannhetsmål. Vi tränar om edge-modellen varje vecka och driftsätter uppdateringar via rullande driftsättning för att undvika stormar av cache-invalidering. Den fullständiga modellen körs på serversidan för fall där edge-modellens konfidens ligger under ett konfigurerbart tröskelvärde.

ClickHouse för analys

Alla berikade händelser lagras i ClickHouse, vår kolumnbaserade analysdatabas. ClickHouse komprimering och frågeprestanda gör att vi kan lagra miljardtals händelser samtidigt som vi stödjer analytiska frågor i realtid. Våra kunder använder denna analys för att förstå bedrägerimönster, finjustera scoring-tröskelvärden och undersöka enskilda händelser.

Vi använder materialiserade vyer i ClickHouse för att underhålla föraggregerade mätvärden: bedrägerifrekvens per land, scoring-fördelning per enhetstyp och andelen falska positiva per tröskelvärde. Dessa materialiserade vyer uppdateras i realtid allteftersom händelser anländer och tillhandahåller dashboard-färdiga mätvärden utan kostsamma aggregeringsfrågor.

Lärdomar

Att bygga ett scoring-system i realtid gav oss flera lärdomar. För det första är förberäkning den viktigaste optimeringen — allt arbete du kan utföra innan scoring-förfrågan anländer är arbete som inte belastar din latensbudget. För det andra passar Go:s samtidighetsmodell väl för händelsebearbetning med hög genomströmning, men man måste vara disciplinerad kring minnesallokering för att undvika GC-tryck. För det tredje är edge-driftsättning omvälvande för latens men kräver noggrann modellhantering för att undvika inaktuella förutsägelser.