Fraudedetectie aan de edge: Cloudflare Workers + tracio.ai

Traditionele fraudedetectie gebeurt op de applicatielaag: de request komt aan bij je server, je bevraagt je fraudedetectie-API, wacht op het antwoord en beslist vervolgens of je toestaat of blokkeert. Deze round-trip voegt 50-200 ms latentie toe aan elke request — acceptabel voor het laden van pagina's, maar pijnlijk voor API-endpoints, AJAX-calls en realtime-interacties.

Wat als je de fraudebeslissing kon nemen voordat de request je origin-server bereikt? Dat is precies wat edge computing mogelijk maakt, en Cloudflare Workers is het platform dat we gebruiken om dit patroon te demonstreren.

De architectuur

De opzet bestaat uit drie componenten: de tracio.ai JS SDK (@tracio/sdk) die in de browser draait, een Cloudflare Worker die tussen de client en je origin zit, en gesigneerde tracio.ai-webhooks die de volledige signaalanalyse aan je backend leveren.

De flow werkt zo: de JS SDK verzamelt device-signalen en stuurt ze tijdens het laden van de pagina naar tracio.ai, waarbij een visitorId aan de browser wordt teruggegeven. Je backend ontvangt het volledige identificatieresultaat — botclassificatie, smart signals, confidence — via een gesigneerde webhook en schrijft het verdict naar een edge-cache. De browser voegt de visitorId toe aan volgende API-requests (via header of cookie). De Cloudflare Worker onderschept elke request, zoekt het gecachte verdict voor die visitorId op en neemt in minder dan 5 ms een allow/block-beslissing.

Implementatie van de Worker

De Worker houdt een lichtgewicht cache bij van recente device-verificatieresultaten met behulp van Cloudflare's KV-storage, die door je backend wordt gevuld zodra gesigneerde tracio.ai-webhooks binnenkomen. Wanneer een request binnenkomt met een visitorId-header, controleert de Worker de cache. Als het verdict gecacht is en de bezoeker schoon is (lage botscore, geen VPN, confidence boven de drempel), gaat de request meteen door. Als er nog geen verdict gecacht is, past de Worker je fallbackbeleid toe — doorlaten met een conservatieve rate limit, of een challenge — totdat de webhook-gestuurde cache is bijgewerkt.

Het cruciale inzicht is dat de verificatiecache proactief wordt gevuld. Het eerste laden van de pagina start de signaalverzameling en cacht het resultaat. Alle volgende API-calls van die bezoeker raken de cache — geen round-trip naar tracio.ai nodig. De cache-TTL is configureerbaar; we raden 5 minuten aan voor endpoints met hoge beveiliging en 30 minuten voor algemene content.

Prestatiecijfers

We hebben deze architectuur gebenchmarkt met een klant die 50.000 requests per minuut door Cloudflare Workers verwerkt. Resultaten:

Cache hit rate: 94% (de meeste requests komen van bezoekers die al een pagina hebben geladen). Edge-beslissingslatentie (cache hit): 1,2 ms mediaan, 3,8 ms p99. Edge-beslissingslatentie (cache miss): 45 ms mediaan (inclusief API-call naar tracio.ai). Bespaarde origin-latentie: 120 ms mediaan per request (server-side fraudecheck geëlimineerd).

De cache hit rate van 94% betekent dat 94% van de fraudebeslissingen in minder dan 4 ms aan de edge plaatsvindt, zonder betrokkenheid van de origin. De overige 6% zijn first-visit-requests die een volledige API-round-trip vereisen.

Blokkeerstrategieën

De Worker ondersteunt drie blokkeerstrategieën, per route configureerbaar:

Hard block: retourneer meteen een 403 voor bezoekers met een hoog risico (botscore > 0,9, bekend automatiseringsframework). Soft block: voeg X-Tracio-Risk-headers toe en laat de origin beslissen. Dit is handig wanneer je context op applicatieniveau wilt voor de beslissing. Challenge: leid verdachte bezoekers (gematigde botscore, VPN gedetecteerd) door naar een challenge-pagina die extra verificatie vereist.

We raden aan te beginnen met soft blocking in productie, de risicoverdeling een week te monitoren en daarna hard blocking in te schakelen voor duidelijke gevallen (bekende bots, headless browsers, automatisering met hoge confidence).

Kostenanalyse

De prijsstelling van Cloudflare Workers is gebaseerd op requests en compute-tijd. Bij 50K requests/minuut (2,16 miljard/maand) bedragen de Worker-kosten ongeveer $500/maand. Vergelijk dat met de latentiebesparing: het elimineren van 120 ms fraudecontrole aan de origin-kant verlaagt het CPU-gebruik van de server met 15-20%, wat doorgaans meer bespaart aan compute dan de Worker kost.

De echte waarde zit in fraudepreventie: het onderscheppen van bots en frauduleuze requests voordat ze origin-resources, databaseverbindingen en downstream-API-calls verbruiken. Eén klant bracht zijn aantal origin-servers terug van 12 naar 8 na het implementeren van edge-gebaseerde fraudedetectie — de bots die 30% van hun compute verbruikten, bereikten de origin nooit.