एज पर फ्रॉड डिटेक्शन: Cloudflare Workers + tracio.ai

पारंपरिक फ्रॉड डिटेक्शन एप्लिकेशन लेयर पर होता है: रिक्वेस्ट आपके सर्वर पर आती है, आप अपने फ्रॉड डिटेक्शन API को क्वेरी करते हैं, रिस्पॉन्स का इंतज़ार करते हैं, और फिर तय करते हैं कि allow करें या block। यह राउंड-ट्रिप हर रिक्वेस्ट में 50-200ms की लेटेंसी जोड़ता है — पेज लोड के लिए स्वीकार्य, लेकिन API endpoints, AJAX कॉल और रियल-टाइम इंटरैक्शन के लिए तकलीफदेह।

क्या हो अगर आप फ्रॉड निर्णय रिक्वेस्ट के आपके ऑरिजिन सर्वर तक पहुँचने से पहले ले सकें? यही एज कंप्यूटिंग संभव बनाती है, और इस पैटर्न को दिखाने के लिए हम Cloudflare Workers प्लेटफ़ॉर्म का उपयोग करते हैं।

आर्किटेक्चर

सेटअप में तीन घटक हैं: ब्राउज़र में चलने वाला tracio.ai JS SDK (@tracio/sdk), क्लाइंट और आपके ऑरिजिन के बीच बैठा एक Cloudflare Worker, और आपके बैकएंड तक पूर्ण सिग्नल विश्लेषण पहुँचाने वाले साइन किए गए tracio.ai webhooks।

फ्लो इस तरह काम करता है: JS SDK पेज लोड के दौरान डिवाइस सिग्नल इकट्ठा करता है और उन्हें tracio.ai को भेजता है, ब्राउज़र को एक visitorId लौटाता है। आपका बैकएंड पूर्ण आइडेंटिफिकेशन परिणाम — bot वर्गीकरण, smart signals, confidence — एक साइन किए गए webhook के ज़रिए प्राप्त करता है और वर्डिक्ट को एज कैश में लिखता है। ब्राउज़र बाद की API रिक्वेस्ट में visitorId शामिल करता है (header या cookie के ज़रिए)। Cloudflare Worker हर रिक्वेस्ट को इंटरसेप्ट करता है, उस visitorId के लिए कैश किए गए वर्डिक्ट को देखता है, और 5ms से कम में allow/block निर्णय लेता है।

Worker कार्यान्वयन

Worker, Cloudflare के KV storage का उपयोग करते हुए हाल के डिवाइस वेरिफिकेशन परिणामों का एक हल्का कैश बनाए रखता है, जिसे साइन किए गए tracio.ai webhooks के आने पर आपका बैकएंड भरता है। जब visitorId header के साथ रिक्वेस्ट आती है, तो Worker कैश जाँचता है। यदि वर्डिक्ट कैश में है और विज़िटर साफ़ है (कम bot स्कोर, कोई VPN नहीं, threshold से ऊपर confidence), तो रिक्वेस्ट तुरंत पास हो जाती है। यदि अभी तक कोई वर्डिक्ट कैश नहीं हुआ है, तो Worker आपकी fallback नीति लागू करता है — एक conservative rate limit के साथ पास, या challenge — जब तक webhook-चालित कैश अद्यतन नहीं हो जाता।

महत्वपूर्ण अंतर्दृष्टि यह है कि वेरिफिकेशन कैश को सक्रिय रूप से भरा जाता है। पहला पेज लोड सिग्नल संग्रह को ट्रिगर करता है और परिणाम को कैश करता है। उस विज़िटर की सभी बाद की API कॉल कैश से पूरी होती हैं — tracio.ai तक राउंड-ट्रिप की ज़रूरत नहीं। कैश TTL configurable है; हम उच्च-सुरक्षा endpoints के लिए 5 मिनट और सामान्य कंटेंट के लिए 30 मिनट की सलाह देते हैं।

प्रदर्शन आँकड़े

हमने इस आर्किटेक्चर को एक ऐसे ग्राहक के साथ बेंचमार्क किया जो Cloudflare Workers के ज़रिए प्रति मिनट 50,000 रिक्वेस्ट प्रोसेस करता है। परिणाम:

कैश हिट रेट: 94% (अधिकांश रिक्वेस्ट उन विज़िटर से आती हैं जो पहले ही कोई पेज लोड कर चुके हैं)। एज निर्णय लेटेंसी (कैश हिट): 1.2ms मीडियन, 3.8ms p99। एज निर्णय लेटेंसी (कैश मिस): 45ms मीडियन (tracio.ai को API कॉल शामिल)। ऑरिजिन लेटेंसी बचत: प्रति रिक्वेस्ट 120ms मीडियन (सर्वर-साइड फ्रॉड जाँच खत्म की गई)।

94% कैश हिट रेट का मतलब है कि 94% फ्रॉड निर्णय एज पर 4ms से कम में होते हैं, बिना किसी ऑरिजिन भागीदारी के। शेष 6% पहली-विज़िट रिक्वेस्ट हैं जिनके लिए पूर्ण API राउंड-ट्रिप की ज़रूरत होती है।

ब्लॉकिंग रणनीतियाँ

Worker तीन ब्लॉकिंग रणनीतियों का समर्थन करता है, जो प्रति route configurable हैं:

हार्ड ब्लॉक: उच्च-जोखिम वाले विज़िटर के लिए तुरंत 403 लौटाएँ (bot स्कोर > 0.9, ज्ञात automation framework)। सॉफ्ट ब्लॉक: X-Tracio-Risk headers जोड़ें और ऑरिजिन को निर्णय लेने दें। यह तब उपयोगी है जब आप निर्णय के लिए एप्लिकेशन-स्तरीय संदर्भ चाहते हों। चैलेंज: संदिग्ध विज़िटर (मध्यम bot स्कोर, VPN का पता चला) को एक challenge पेज पर रीडायरेक्ट करें जिसके लिए अतिरिक्त वेरिफिकेशन चाहिए।

हम production में सॉफ्ट ब्लॉकिंग से शुरू करने, एक सप्ताह तक जोखिम वितरण की निगरानी करने, और फिर स्पष्ट मामलों (ज्ञात bots, headless browsers, उच्च-confidence automation) के लिए हार्ड ब्लॉकिंग सक्षम करने की सलाह देते हैं।

लागत विश्लेषण

Cloudflare Workers की कीमत रिक्वेस्ट और compute समय पर आधारित है। 50K रिक्वेस्ट/मिनट (2.16 अरब/माह) पर, Worker की लागत लगभग $500/माह है। इसकी तुलना लेटेंसी बचत से करें: 120ms की ऑरिजिन-साइड फ्रॉड जाँच खत्म करने से सर्वर CPU उपयोग 15-20% घटता है, जो आमतौर पर compute में Worker की लागत से अधिक बचाता है।

असली मूल्य फ्रॉड रोकथाम में है: bots और फ्रॉड रिक्वेस्ट को ऑरिजिन संसाधनों, डेटाबेस कनेक्शन और downstream API कॉल का उपभोग करने से पहले पकड़ना। एक ग्राहक ने एज-आधारित फ्रॉड डिटेक्शन लागू करने के बाद अपने ऑरिजिन सर्वर की संख्या 12 से घटाकर 8 कर दी — जो bots उनके 30% compute का उपभोग कर रहे थे, वे कभी ऑरिजिन तक नहीं पहुँचे।