Echtzeit-Betrugsbewertung im großen Maßstab
Wie tracio.ai 50.000 Events/Sekunde mit einer Bewertung unter 50ms verarbeitet — mittels Stream-Processing, vorberechneter Signalvektoren und Edge-Caching.
Betrugsbewertung im großen Maßstab erfordert eine grundlegend andere Architektur als Batch-Verarbeitung. Wenn eine Zahlung autorisiert oder ein Konto erstellt wird, haben Sie Millisekunden — nicht Minuten — um einen Risikowert zu liefern. Bei tracio.ai verarbeiten wir über 50.000 Events pro Sekunde mit einer medianen Bewertungslatenz von 22ms. Dieser Artikel erklärt die Architektur, die das möglich macht.
Die Bewertungs-Pipeline
Jedes eingehende Event durchläuft eine dreistufige Pipeline: Signalanreicherung, Vektorberechnung und Risikobewertung. Die Signalanreicherung hängt Device-Intelligence-Daten an das Rohevent an — den Fingerprint des Besuchers, Ergebnisse der Bot-Erkennung, IP Intelligence und historisches Verhalten. Die Vektorberechnung transformiert diese angereicherten Signale in einen Feature-Vektor fester Länge, der für unser Bewertungsmodell optimiert ist. Die Risikobewertung führt den Vektor durch unser trainiertes Modell und liefert einen Wert zwischen 0.0 und 1.0 zurück.
Die zentrale Designentscheidung ist, dass Anreicherung und Vektorberechnung von der Bewertung getrennt sind. Anreicherungsdaten werden vorberechnet und gecacht. Wenn ein Besucher eine Seite lädt, berechnen wir sein Geräteprofil und speichern es in Redis mit einer TTL von 60 Minuten. Wenn eine Bewertungsanfrage eintrifft — typischerweise ausgelöst durch eine Zahlung oder ein Login — rufen wir das vorberechnete Profil ab, anstatt es neu zu berechnen. Dies reduziert die Bewertungslatenz von über 200ms auf unter 30ms.
Stream-Processing mit Go
Unsere Ingestion-Schicht ist in Go geschrieben und nutzt eine Fan-out-Architektur. Eingehende Events treffen per HTTP POST ein und werden sofort auf einen internen Channel gelegt. Ein Pool von Worker-Goroutinen liest aus diesem Channel, führt die Anreicherung durch und schreibt die angereicherten Events zur Analyse nach ClickHouse und in eine Bewertungs-Queue für die Echtzeitverarbeitung. Der Fan-out-Pool skaliert dynamisch anhand der Queue-Tiefe.
Wir haben Go für die Ingestion-Schicht gewählt wegen seiner hervorragenden Concurrency-Primitive und der vorhersagbaren Speicherallokation. Jede Worker-Goroutine verbraucht etwa 4KB Stack-Speicher, was uns erlaubt, Tausende gleichzeitiger Worker auf einem einzelnen Knoten auszuführen. Die Submillisekunden-Pausen des Garbage Collectors sind entscheidend, um bei hohem Durchsatz eine konsistente Latenz aufrechtzuerhalten.
Edge-Caching und Signalvektoren
Für unsere Kunden mit dem höchsten Volumen setzen wir Bewertungsmodelle am Edge ein, unter Verwendung eines Caches vorberechneter Signalvektoren. Wenn ein Gerät zum ersten Mal gesehen wird, berechnen wir seinen vollständigen Signalvektor und speichern ihn in unserem Edge-Cache (bereitgestellt auf Cloudflare Workers KV). Nachfolgende Bewertungsanfragen für dasselbe Gerät rufen den gecachten Vektor ab und führen die Bewertung lokal am Edge aus, wodurch eine Latenz unter 10ms erreicht wird.
Das Edge-Bewertungsmodell ist eine destillierte Version unseres vollständigen Modells — kleiner und schneller, aber für dieselben Genauigkeitsziele optimiert. Wir trainieren das Edge-Modell wöchentlich neu und verteilen Updates über ein Rolling Deployment, um Cache-Invalidierungsstürme zu vermeiden. Das vollständige Modell läuft serverseitig für Fälle, in denen die Konfidenz des Edge-Modells unter einem konfigurierbaren Schwellenwert liegt.
ClickHouse für Analysen
Alle angereicherten Events werden in ClickHouse gespeichert, unserer spaltenorientierten Analysedatenbank. Die Kompression und Query-Performance von ClickHouse erlauben es uns, Milliarden von Events zu speichern und dabei analytische Echtzeit-Queries zu unterstützen. Unsere Kunden nutzen diese Analysen, um Betrugsmuster zu verstehen, Bewertungsschwellen zu justieren und einzelne Events zu untersuchen.
Wir verwenden Materialized Views in ClickHouse, um voraggregierte Metriken zu pflegen: Betrugsrate nach Land, Bewertungsverteilung nach Gerätetyp und False-Positive-Raten nach Schwellenwert. Diese Materialized Views aktualisieren sich in Echtzeit, sobald Events eintreffen, und liefern dashboard-fertige Metriken ohne teure Aggregationsabfragen.
Gelernte Lektionen
Der Aufbau eines Echtzeit-Bewertungssystems hat uns mehrere Lektionen gelehrt. Erstens: Vorberechnung ist die wichtigste Optimierung — jede Arbeit, die Sie erledigen können, bevor die Bewertungsanfrage eintrifft, ist Arbeit, die nicht auf Ihr Latenzbudget angerechnet wird. Zweitens: Gos Concurrency-Modell eignet sich gut für die Verarbeitung von Events mit hohem Durchsatz, aber Sie müssen bei der Speicherallokation diszipliniert sein, um GC-Druck zu vermeiden. Drittens: Edge-Deployment ist transformativ für die Latenz, erfordert aber sorgfältiges Modellmanagement, um veraltete Vorhersagen zu vermeiden.