सिस्टम डिज़ाइन इंटरव्यू: एक रियल-टाइम पेमेंट फ्रॉड डिटेक्शन प्लेटफॉर्म डिज़ाइन करें

प्रॉम्प्ट और प्रासंगिक संदर्भ

एक रियल-टाइम पेमेंट फ्रॉड डिटेक्शन प्लेटफॉर्म डिज़ाइन करें। यह पेमेंट ऑथराइजेशन से पहले काम करता है और चार में से कोई एक एक्शन लौटाता है: ALLOW, STEP_UP, REVIEW, या BLOCK। एक step-up अतिरिक्त ऑथेंटिकेशन का अनुरोध करता है। एक review फुलफिलमेंट या किसी अन्य प्रतिवर्ती (reversible) व्यावसायिक कार्रवाई में देरी कर सकता है, लेकिन फ्रॉड सर्विस खुद पैसे कैप्चर नहीं करती है।

औसतन 1,000 रिक्वेस्ट प्रति सेकंड और पीक पर 5,000 प्रति सेकंड मानकर चलें। प्रत्येक रिक्वेस्ट लगभग 1.5 KB की है। सिंक्रोनस निर्णय का p99 100 मिलीसेकंड से कम और 99.99% मासिक उपलब्धता (availability) का लक्ष्य है। ऑपरेशन्स प्रति दिन अधिकतम 10,000 केसों की मैन्युअल समीक्षा कर सकते हैं। डिसीजन रिकॉर्ड सात दिनों तक खोजने योग्य होने चाहिए और रॉ इवेंट्स को 400 दिनों तक आर्काइव किया जाना चाहिए। ये संख्याएँ इंटरव्यू के उद्देश्य से ली गई धारणाएँ हैं, किसी वास्तविक प्रोडक्ट या कानूनी प्रतिधारण (retention) आवश्यकताओं के बारे में दावे नहीं हैं।

पेमेंट सर्विस टोकनाइज़्ड पेमेंट-इंस्ट्रूमेंट, अकाउंट, मर्चेंट, डिवाइस, नेटवर्क, राशि, करेंसी और इवेंट-टाइम एट्रिब्यूट्स भेजती है। फ्रॉड प्लेटफॉर्म को रॉ कार्ड नंबर या सुरक्षा कोड प्राप्त नहीं होना चाहिए। यह रिस्क डिसीजन्स, रूल और मॉडल वर्जन्स, ऑनलाइन रिस्क फीचर्स, रिव्यू केस और फीडबैक लेबल्स का प्रबंधन करता है। पेमेंट ऑथराइजेशन, 3DS निष्पादन, विवाद (disputes), और मनी लेज़र का स्वामित्व उनके संबंधित सिस्टम्स के पास रहता है।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत यह है कि क्या उम्मीदवार मॉडल की सटीकता को अलग-थलग रूप से अनुकूलित करने के बजाय एक डिसीजन कॉन्ट्रैक्ट को परिभाषित करता है। फ्रॉड लॉस, गलत ब्लॉक्स (false blocks), अतिरिक्त ऑथेंटिकेशन फ्रिक्शन, रिव्यू क्षमता, लेटेंसी और उपलब्धता—ये सभी पॉलिसी को सीमित करते हैं। मॉडल स्कोर एक साक्ष्य (evidence) है; एक वर्ज़न की गई पॉलिसी साक्ष्य को एक एक्शन में बदलती है।

दूसरा संकेत समय की सटीकता (time correctness) है। वेलोसिटी फीचर्स में मौजूदा प्रयास शामिल होना चाहिए, बिना किसी आइडेम्पोटेंट पुनर्प्रयास (retry) को दो बार गिने। ऐतिहासिक ट्रेनिंग फीचर्स में केवल वही जानकारी होनी चाहिए जो मूल निर्णय के समय उपलब्ध थी। चार्ज-बैक और एनालिस्ट परिणाम बाद में आते हैं, इसलिए बिना लेबल वाला लेन-देन तुरंत नकारात्मक उदाहरण नहीं बन सकता।

तीसरा संकेत एक सीमित सिंक्रोनस पाथ है। यह पहचान और स्कीमा की जाँच करता है, एक छोटा बैच्ड फीचर स्नैपशॉट पढ़ता है, रूल्स और एक प्रोडक्शन मॉडल का मूल्यांकन करता है, पॉलिसी लागू करता है, एक रीप्ले करने योग्य निर्णय को बनाए रखता है, और वापस लौटता है। ग्लोबल ग्राफ ट्रैवर्सल, बड़े जॉइन्स, मॉडल ट्रेनिंग और केस एनालिटिक्स क्रिटिकल पाथ से बाहर रहने चाहिए। ग्राफ या बैच जॉब्स कॉम्पैक्ट रिस्क फीचर्स पब्लिश करते हैं जिन्हें सिंक्रोनस सर्विस पढ़ सकती है।

चौथा संकेत स्पष्ट डिग्रेडेशन (explicit degradation) है। एक पुराना (stale) फीचर सुरक्षित फीचर के समान नहीं होता है, और एक अनुपलब्ध मॉडल शून्य स्कोर के बराबर नहीं होता है। फीचर की ताजगी (freshness), राशि, प्रभावित एंटिटी और उपलब्ध फॉलबैक के अनुसार एक्शन बदलता है। एक मजबूत उत्तर यह निर्दिष्ट करता है कि प्रत्येक डिपेंडेंसी फेलियर के दौरान कब allow, step up, review या block करना है।

अंतिम संकेत मिथ्याकरणीयता (falsifiability) है। प्रत्येक निर्णय में रिक्वेस्ट डाइजेस्ट, फीचर प्रोवेनेंस, हिट हुए रूल्स, मॉडल और पॉलिसी वर्जन्स, स्कोर, एक्शन, रीज़न कोड और लेटेंसी दर्ज होती है। ऐतिहासिक रीप्ले, पॉइंट-इन-टाइम फीचर चेक्स, डुप्लीकेट और आउट-ऑफ-ऑर्डर इवेंट्स, हॉट-की लोड, डिपेंडेंसी फेलियर्स, एडवरसैरियल ट्रैफिक और शैडो या कैनरी तुलना के माध्यम से फिर डिज़ाइन का परीक्षण किया जा सकता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• प्लेटफॉर्म कहाँ स्थित है? यह डिज़ाइन ऑथराइजेशन से पहले एक सिंक्रोनस निर्णय लेता है। विशुद्ध रूप से एसिंक्रोनस

डिटेक्टर फ्रॉड रिंग्स ढूंढ सकता है और जांच का समर्थन कर सकता है लेकिन वर्तमान भुगतान को रोक नहीं सकता है।

• कौन से एक्शन्स उपलब्ध हैं? प्रॉम्प्ट चार एक्शन्स प्रदान करता है। REVIEW 10,000-केस के दैनिक बजट द्वारा सीमित है;

यह प्रत्येक अनिश्चित स्कोर के लिए एक सुविधाजनक उत्तर नहीं हो सकता है। पेमेंट प्रोडक्ट यह परिभाषित करता है कि केस लंबित रहने के दौरान क्या प्रतिवर्ती (reversible) है।

• कौन से आइडेंटिफायर्स प्रदान किए जाते हैं? एक स्थिर decision_id, टोकनाइज़्ड इंस्ट्रूमेंट आईडी, मौजूद होने पर अकाउंट आईडी,

मर्चेंट आईडी और डिवाइस आईडी की आवश्यकता होती है। रॉ कार्ड डेटा सीमा से बाहर है। अनुपलब्ध वैकल्पिक पहचान एक स्पष्ट फीचर बन जाती है, कोई गढ़ी हुई वैल्यू नहीं।

• प्रत्येक फीचर कितना ताज़ा होना चाहिए? दस मिनट का वेलोसिटी रूल एक घंटे पुराने काउंटर का उपयोग नहीं कर सकता है। प्रत्येक फीचर ग्रुप की एक

अधिकतम आयु और फॉलबैक पॉलिसी होती है। प्रोफाइल फीचर्स मिनटों को सहन कर सकते हैं; क्रिटिकल वेलोसिटी स्टेट केवल सेकंड्स को सहन कर सकती है।

• लेबल्स कैसे और कब आते हैं? एनालिस्ट का निर्णय एक प्रारंभिक लेकिन त्रुटिपूर्ण संकेत है। बाद में पुष्टि किया गया विवाद एक

मजबूत लेबल होता है। लेबल स्रोत, अवलोकन समय, मैच्योरिटी स्थिति और वर्ज़न को संग्रहीत किया जाना चाहिए ताकि सुधार इतिहास को अदृश्य रूप से फिर से न लिखें।

• क्या क्रॉस-एंटिटी ग्राफ डिटेक्शन सिंक्रोनस है? 100-मिलीसेकंड के बजट के तहत किसी ग्लोबल ट्रैवर्सल की आवश्यकता नहीं है।

ऑफलाइन या स्ट्रीमिंग ग्राफ जॉब्स कॉम्पैक्ट एंटिटी-रिस्क या नेबरहुड-रिस्क फीचर्स पब्लिश करते हैं। एक इंसिडेंट-विशिष्ट लुकअप केवल उसकी लेटेंसी और उपलब्धता को मापने के बाद ही जोड़ा जा सकता है।

• फेलियर की स्थिति (fail posture) क्या है? इसका कोई सार्वभौमिक फेल-ओपन या फेल-क्लोज़्ड उत्तर नहीं है। कम मूल्य वाले ज्ञात ग्राहकों को

रूल्स फॉलबैक के तहत अनुमति दी जा सकती है, जबकि उच्च मूल्य वाले नए-डिवाइस भुगतानों के लिए क्रिटिकल फीचर्स अनुपलब्ध होने पर step-up या block की आवश्यकता हो सकती है।

• प्राइवेसी की सीमाएं क्या हैं? प्रतिधारण (retention), भौगोलिक प्रोसेसिंग, जांच पहुंच और फीचर की वैधता की

सुरक्षा, गोपनीयता और अनुपालन स्वामियों के साथ पुष्टि की जानी चाहिए। यह उत्तर आइडेंटिफायर्स को न्यूनतम करता है और पहुंच का ऑडिट करता है लेकिन कोई क्षेत्राधिकार-विशिष्ट नियम नहीं गढ़ता है।

30-सेकंड का उत्तर फ्रेमवर्क

“मैं एक वर्ज़न्ड डिसीजन कॉन्ट्रैक्ट के साथ शुरुआत करूँगा: एक decision_id, अपरिवर्तनीय (immutable) रिक्वेस्ट डाइजेस्ट, चार एक्शन्स, एक 100-मिलीसेकंड का p99 बजट और एक सख्त रिव्यू-क्षमता सीमा। सिंक्रोनस सर्विस ताज़ा ऑनलाइन फीचर्स को बैच में पढ़ती है, आइडेम्पोटेंट प्रति-एंटिटी वेलोसिटी काउंट्स प्राप्त करती है जिसमें वर्तमान प्रयास शामिल होता है, हार्ड रूल्स और एक मॉडल का मूल्यांकन करती है, फिर एक पॉलिसी लागू करती है और वापस लौटने से पहले सभी प्रोवेनेंस को स्थायी रूप से रिकॉर्ड करती है। इवेंट्स एक स्ट्रीम प्रोसेसर और एक ऑफलाइन स्टोर को भी फीड करते हैं। ट्रेनिंग पॉइंट-इन-टाइम फीचर्स और वर्ज़न्ड, मैच्योर लेबल्स का उपयोग करती है। ग्लोबल ग्राफ का काम एसिंक्रोनस रहता है और कॉम्पैक्ट रिस्क फीचर्स पब्लिश करता है। अनुपलब्ध या पुरानी डिपेंडेंसीज़ एक राशि- और पहचान-जागरूक डिग्रेडेशन मैट्रिक्स को ट्रिगर करती हैं, न कि एक मूक शून्य स्कोर को। शैडो रीप्ले, कैनरीज़, हॉट-की टेस्ट्स और फेलियर इंजेक्शन फ्रॉड परिणामों और ग्राहक फ्रिक्शन दोनों को सत्यापित करते हैं।”

चरण-दर-चरण गहन विश्लेषण

स्टेप 1: प्रॉम्प्ट को बजट्स और इनवेरिएंट्स में बदलें

1,000 रिक्वेस्ट प्रति सेकंड पर, प्लेटफॉर्म प्रति दिन 86.4 मिलियन निर्णय देखता है। एक 1.5 KB की रिक्वेस्ट रेप्लिकेशन और इंडेक्सिंग से पहले प्रति दिन लगभग 129.6 GB रॉ इनग्रेस उत्पन्न करती है; 5,000-प्रति-सेकंड का पीक लगभग 7.5 MB प्रति सेकंड है। यदि एक कॉम्पैक्ट डिसीजन रिकॉर्ड औसतन 2 KB का है, तो सात सक्रिय दिन इंडेक्स और रेप्लिका से पहले लगभग 1.21 TB होते हैं। ये साइजिंग एंकर हैं, सटीक स्टोरेज पूर्वानुमान नहीं। कम्प्रेशन, स्कीमा ओवरहेड और इंडेक्स को मापा जाना चाहिए।

रिव्यू बजट अधिक सख्त प्रोडक्ट बाधा है: 10,000 केस 86.4 मिलियन दैनिक निर्णयों का केवल लगभग 0.012% हैं। इसलिए पॉलिसी को प्राथमिकता और एडमिशन कंट्रोल की आवश्यकता होती है। जब कतार भर जाती है, तो इसे अपेक्षित नुकसान और फ्रिक्शन के अनुसार सबसे कम प्राथमिकता वाले रिव्यू बैंड को एक गार्डरेल के साथ ALLOW, STEP_UP, या BLOCK में स्थानांतरित करना होगा; यह एक असीमित बैकलॉग नहीं बना सकता।

रिव्यू कोटा को डिसीजन सर्विस के ऑथॉरिटेटिव डेटाबेस में रखें। एक सशर्त दैनिक काउंटर, जिसे वैकल्पिक रूप से आरक्षित रिस्क बैंड में विभाजित किया गया है, उसी ट्रांजैक्शन में decision_id द्वारा क्लेम किया जाता है जो निर्णय और रिव्यू केस बनाता है। कम रिव्यू वॉल्यूम एक अलग डिस्ट्रिब्यूटेड कोटा सिस्टम को उचित नहीं ठहराता है। यदि क्लेम विफल हो जाता है, तो पॉलिसी कमिट करने से पहले घोषित ओवरफ्लो एक्शन का मूल्यांकन करती है, ताकि समवर्ती (concurrent) सर्वर दैनिक सीमा से अधिक एडमिट न कर सकें।

एक उदाहरणात्मक 100-मिलीसेकंड का बजट इस प्रकार है: ऑथेंटिकेशन और वैलिडेशन के लिए 8 मिलीसेकंड, बैच्ड ऑनलाइन फीचर्स और वेलोसिटी स्टेट के लिए 25, रूल्स के लिए 10, मॉडल इन्फरेंस के लिए 20, पॉलिसी प्लस ड्यूरेबल डिसीजन राइट के लिए 15, और नेटवर्क व टेल-लेटेंसी हेडरूम के लिए 22। प्रत्येक चरण को उसके बजट से छोटा टाइमआउट मिलता है। इनवेरिएंट्स निम्नलिखित हैं:

one decision_id identifies one immutable request digest
an idempotent retry returns the original decision and does not increment velocity twice
every returned action has a persisted policy, model, rule, and feature provenance record
missing or expired critical features cannot be interpreted as normal values
review admissions never exceed the configured operational capacity
training features contain only values available at the historical decision time
labels retain source, observation time, maturity state, and version
raw payment card data never enters the fraud platform

स्टेप 2: API और डिसीजन रिकॉर्ड को परिभाषित करें

सिंक्रोनस इंटरफ़ेस को सीमित रखें:

POST /v1/risk/decisions              create or replay a decision
GET  /v1/risk/decisions/{decision_id} read the immutable result and current case status
POST /v1/reviews/{case_id}/disposition record an analyst outcome
POST /v1/feedback                     ingest a dispute or trusted fraud outcome

क्रिएट रिक्वेस्ट में decision_id, event_at, राशि और करेंसी, टोकनाइज़्ड एंटिटी आईडीज़, मर्चेंट और चैनल, और वर्तमान रिक्वेस्ट एट्रिब्यूट्स शामिल हैं। रिस्पॉन्स में action, स्थिर रीज़न कोड्स, वैकल्पिक step-up प्रकार या रिव्यू केस आईडी, और decision_version शामिल हैं। decision_id पर एक यूनिक की एक सामान्यीकृत रिक्वेस्ट हैश को स्टोर करती है। समान आईडी और हैश मूल रिस्पॉन्स को रीप्ले करते हैं; एक अलग पेलोड के साथ समान आईडी एक कॉन्फ्लिक्ट लौटाती है।

अलग-अलग जिम्मेदारियों को स्टोर करें:

• risk_decisions: आइडेंटिफायर्स, रिक्वेस्ट हैश, इवेंट टाइम, स्कोर, एक्शन, रीज़न कोड्स, फीचर स्नैपशॉट और फ्रेशनेस,

रूल बंडल, मॉडल, पॉलिसी वर्जन्स, लेटेंसी, और डिग्रेडेशन स्टेट;

• review_cases: डिसीजन रेफरेंस, प्राथमिकता, कतार स्थिति, असाइनी, निर्णय (disposition), और टाइमस्टैम्प्स;
• feedback_labels: डिसीजन रेफरेंस, लेबल, स्रोत, देखा गया समय, मैच्योरिटी स्थिति, कॉन्फिडेंस, और वर्ज़न;
• policy_bundles: हस्ताक्षरित अपरिवर्तनीय रूल, थ्रेशोल्ड, रिव्यू-बजट, और फॉलबैक कॉन्फ़िगरेशन;
• outbox_events: कमिट किया गया डिसीजन इवेंट जो एसिंक्रोनस पब्लिकेशन की प्रतीक्षा कर रहा है।

वापस लौटने से पहले एक लोकल ट्रांजैक्शन में डिसीजन और आउटबॉक्स इवेंट को बनाए रखें। इवेंट स्ट्रीम एट-लीस्ट-वन्स है, इसलिए डाउनस्ट्रीम कंज्यूमर्स decision_id और इवेंट वर्ज़न द्वारा डुप्लीकेट हटाते हैं। पेमेंट सर्विस अपरिवर्तनीय परिणाम को नामित रिक्वेस्ट के लिए सलाह मानती है; यह किसी अन्य राशि या इंस्ट्रूमेंट के लिए परिणाम का पुन: उपयोग नहीं कर सकती है।

स्टेप 3: सिंक्रोनस पाथ को लर्निंग पाइपलाइनों से अलग करें

सिंक्रोनस डेटा फ्लो इस प्रकार है:

payment service
  -> decision API
  -> idempotency lookup
  -> batched online feature + velocity read
  -> hard rules
  -> model inference
  -> versioned action policy
  -> decision store + outbox
  -> ALLOW | STEP_UP | REVIEW | BLOCK

एसिंक्रोनस फ्लो डिसीजन, ऑथेंटिकेशन, पेमेंट-रिज़ल्ट, रिव्यू और विवाद इवेंट्स का उपभोग करता है। एक स्ट्रीम प्रोसेसर उन्हें डिडुप्लिकेट करता है, इवेंट-टाइम विंडोज़ लागू करता है, और ऑनलाइन एंटिटी फीचर्स को अपडेट करता है जैसे दस मिनट में प्रयास, एक घंटे में विशिष्ट मर्चेंट्स, राशि विचलन, डिवाइस की आयु, और हाल ही में विफल ऑथेंटिकेशन। रॉ अपरिवर्तनीय इवेंट्स और फीचर इतिहास विश्लेषण और ट्रेनिंग के लिए एक ऑफलाइन स्टोर में भी प्रवेश करते हैं।

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

रूल्स और मॉडल एक दूसरे के पूरक हैं। हार्ड पॉलिसी बाधाएं, विश्वसनीय ब्लॉकलिस्ट और उच्च-कॉन्फिडेंस वाले वेलोसिटी लिमिट्स स्पष्ट और तेज़ हैं। मॉडल कमजोर संकेतों और इंटरैक्शन्स को जोड़ता है। अंतिम पॉलिसी रूल रिज़ल्ट्स, स्कोर, फ्रेशनेस, राशि, पहचान कॉन्फिडेंस और रिव्यू क्षमता को एक एक्शन में मैप करती है। केवल-मॉडल डिज़ाइन को इंसिडेंट्स के दौरान संचालित करना कठिन होता है; केवल-रूल्स डिज़ाइन एक मान्य पहला वर्ज़न है लेकिन व्यवहार बदलने पर कमजोर हो जाता है।

स्टेप 4: वेलोसिटी फीचर्स में मौजूदा प्रयास को ठीक एक बार शामिल करें

स्ट्रीम-अपडेटेड काउंटर उस रिक्वेस्ट से पीछे छूट सकता है जिसे स्कोर किया जा रहा है। एक साथ होने वाले दो कार्ड-टेस्टिंग प्रयास दोनों एक ही पुरानी संख्या को पढ़ सकते हैं। क्रिटिकल वेलोसिटी रूल्स के एक छोटे सेट के लिए, एक पार्टीशन्ड रिस्क-स्टेट सर्विस का उपयोग करें जिसमें एक आइडेम्पोटेंट ऑपरेशन हो, जैसे:

observe(entity_type, entity_id, window, decision_id, event_at, value)
  -> count, sum, distinct_estimate, state_version, freshness

सर्विस प्रति एंटिटी की के अनुसार अपडेट्स को ऑर्डर करती है, विंडो की डिडुप्लिकेशन स्थिति में decision_id को स्टोर करती है, वर्तमान प्रयास को शामिल करती है, और परिणामी संख्या लौटाती है। इसलिए एक पुनः प्रयास फिर से बढ़ाने के बजाय वही अवलोकन लौटाता है। स्टेट पार्टिशन्स को इवेंट लॉग से रेप्लिकेट किया जाता है, चेकपॉइंट किया जाता है और फिर से बनाया जाता है। उच्च-कार्डिनैलिटी वाले सन्निकट (approximate) विशिष्ट फीचर्स बाउंडेड स्केच का उपयोग कर सकते हैं, जबकि सटीक ब्लॉक थ्रेशोल्ड सटीक काउंटर्स का उपयोग करते हैं।

एक लेन-देन अकाउंट, इंस्ट्रूमेंट, डिवाइस, आईपी प्रीफ़िक्स और मर्चेंट को छूता है। प्रत्येक एंटिटी में एक ग्लोबल एटॉमिक ट्रांजैक्शन लेटेंसी और उपलब्धता को नुकसान पहुंचाएगा। प्रति-एंटिटी आइडेम्पोटेंसी के साथ समानांतर में उन्हें क्वेरी करें। यदि कोई सबसेट टाइम आउट हो जाता है, तो रिकॉर्ड करें कि कौन सा समूह अनुपलब्ध है और पॉलिसी को डिग्रेड होने दें; कभी भी अनुपलब्ध वैल्यू को शून्य से न बदलें। ज्ञात हॉट एंटिटीज का अलग से रूट और कैपेसिटी टेस्ट करें क्योंकि हमला किया गया इंस्ट्रूमेंट या आईपी ट्रैफ़िक को एक पार्टीशन पर केंद्रित कर सकता है, भले ही कुल QPS सामान्य हो।

इवेंट-टाइम प्रोसेसिंग को डुप्लिकेट्स, लेट इवेंट्स और निष्क्रिय पार्टिशन्स को संभालना चाहिए। वॉटरमार्क इवेंट-टाइम प्रगति का वर्णन करते हैं; वे लेट डेटा को गायब नहीं करते हैं। प्रति फीचर एक अनुमत विलंबता परिभाषित करें, एक उच्च फीचर वर्ज़न के साथ सुधार उत्सर्जित करें, और वॉटरमार्क देरी की निगरानी करें। ऑनलाइन निर्णय वही सटीक स्नैपशॉट रखते हैं जो उन्होंने देखा था। बाद में किया गया सुधार भविष्य के निर्णयों और ऑफलाइन विश्लेषण में सुधार करता है, लेकिन यह नाटक नहीं करता कि पूर्व सेवा को सही वैल्यू पता थी।

स्टेप 5: फ्रेशनेस और एक सुविचारित डिग्रेडेशन मैट्रिक्स लागू करें

प्रत्येक फीचर ग्रुप computed_at, सोर्स इवेंट टाइम, वर्ज़न और अधिकतम अनुमत आयु लौटाता है। फीचर सर्विस FRESH, STALE, MISSING, या ERROR प्राप्त करती है; पॉलिसी उस स्थिति का सीधे उपभोग करती है। मॉडल को केवल अपेक्षित विरल (sparse) डेटा के लिए प्रशिक्षित मिसिंग इंडिकेटर्स प्राप्त होने चाहिए, साधारण नल (nulls) के रूप में प्रच्छन्न आउटेज के लिए नहीं।

एक ठोस फेलियर मैट्रिक्स का उपयोग करें:

सटीक सेल्स व्यावसायिक निर्णय हैं, लेकिन उन्हें वर्ज़न्ड और परीक्षण किया जाना चाहिए। पूर्ण फेल-ओपन एक आउटेज को नुकसान में बदल सकता है; पूर्ण फेल-क्लोज़्ड इसे ग्राहक और राजस्व आउटेज में बदल सकता है। यदि मॉडल और क्रिटिकल वेलोसिटी स्टेट दोनों गायब हैं, तो पॉलिसी राशि, विश्वसनीय पहचान, मर्चेंट रिस्क और ऑथेंटिकेशन उपलब्धता का उपयोग कर सकती है, लेकिन इसे एक विशिष्ट डिग्रेडेड रीज़न दिखाना चाहिए और ऑपरेटरों को पेज करना चाहिए।

स्टेप 6: पॉइंट-इन-टाइम ट्रेनिंग डेटा और परिवर्तनशील लेबल इतिहास बनाएं

प्रत्येक ऐतिहासिक निर्णय के लिए, उसकी decision_at को सीमा के रूप में उपयोग करें। एक फीचर पंक्ति केवल तभी पात्र होती है जब अंतर्निहित इवेंट हुआ हो और उस समय तक उपलब्ध हो गया हो। पॉइंट-इन-टाइम जॉइन्स में देर से आगमन का हिसाब होना चाहिए; आज के संशोधित वेयरहाउस से पिछले महीने की सात-दिवसीय गणना को फिर से कंप्यूट करने से वह जानकारी लीक हो जाएगी जो ऑनलाइन सर्विस के पास नहीं थी।

लेबल्स का एक जीवनचक्र होता है:

UNOBSERVED -> PROVISIONAL_ANALYST_OUTCOME -> MATURE_CONFIRMED_OUTCOME
                                      \-> CORRECTED_VERSION

सटीक मैच्योरिटी पॉलिसी पेमेंट और विवाद प्रक्रिया पर निर्भर करती है। बाद में विवाद आने पर एनालिस्ट के निर्णय को अधिलेखित (overwrite) करने के बजाय प्रत्येक लेबल वर्ज़न को स्टोर करें। ट्रेनिंग एक घोषित लेबल परिभाषा और मैच्योरिटी कटऑफ़ का चयन करती है। मूल्यांकन फॉरवर्ड टाइम स्प्लिट्स, डुप्लिकेट्स या जुड़े मामलों के लिए एंटिटी-जागरूक चेक्स, और एक अंतिम अछूते समय विंडो का उपयोग करता है। ऑफलाइन और ऑनलाइन फीचर पैरिटी टेस्ट्स दोनों कार्यान्वयनों के माध्यम से समान रॉ इवेंट्स को रीप्ले करते हैं और निर्णय सीमा पर वैल्यूज की तुलना करते हैं।

कुल सटीकता (precision) से अधिक की निगरानी करें। फ्रॉड लॉस या रोके गए नुकसान, फॉल्स-पॉजिटिव वैल्यू और दर, ऑथराइजेशन और step-up पूर्णता, रिव्यू यील्ड और कतार आयु, स्कोर कैलिब्रेशन, फीचर ड्रिफ्ट, लेबल कवरेज, और मर्चेंट, चैनल, भूगोल, भुगतान विधि, राशि बैंड, और पहचान स्थिति के अनुसार प्रदर्शन को मापें जहाँ ऐसा विभाजन वैध है। एक थ्रेशोल्ड जो विश्व स्तर पर अच्छा दिखता है वह चुपचाप एक सेगमेंट को ब्लॉक कर सकता है।

स्टेप 7: ग्राफ डिटेक्शन को क्रिटिकल पाथ से बाहर रखें

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

यह एक ज्ञात डिटेक्शन विलंब बनाता है। एक नए खोजे गए अभियान के लिए, ऑपरेटर एक संकीर्ण हस्ताक्षरित नियम या ब्लॉकलिस्ट तैनात कर सकता है जबकि ग्राफ पाइपलाइन तालमेल बिठाती है। भविष्य की सिंक्रोनस ग्राफ क्वेरी केवल तभी उचित होती है जब रीप्ले भौतिक वृद्धिशील रोकथाम दिखाता है, इसका p99 शेष बजट में फिट बैठता है, और इसके आउटेज में एक स्पष्ट फॉलबैक होता है। ग्राफ साक्ष्य को एक अस्पष्टीकृत स्कोर के बजाय अन्वेषक-पठनीय पाथ्स या रीज़न कोड्स भी उत्पन्न करने चाहिए।

स्टेप 8: सिस्टम को रोल आउट, सुरक्षित, मॉनिटर और सत्यापित करें

रूल्स, मॉडल्स, फीचर्स और पॉलिसी थ्रेशोल्ड्स के स्वतंत्र अपरिवर्तनीय वर्जन्स होते हैं लेकिन एक हस्ताक्षरित पॉलिसी बंडल निर्णय के लिए उपयोग किए गए संयोजन को पिन करता है। एक नया बंडल पहले मैच्योर ऐतिहासिक ट्रैफ़िक को रीप्ले करता है, फिर बिना किसी कार्रवाई को बदले शैडो में चलता है, फिर एक छोटा कैनरी स्लाइस प्राप्त करता है। प्रमोशन फ्रॉड लॉस, फॉल्स पॉजिटिव्स, अप्रूवल, step-up पूर्णता, रिव्यू एडमिशन और यील्ड, लेटेंसी, फीचर फ्रेशनेस और फॉलबैक दर की तुलना करता है। रोलबैक सक्रिय बंडल पॉइंटर को बदलता है; पुराने निर्णय पुनरुत्पादन योग्य रहते हैं।

सर्विस टोकनाइज़्ड आईडी स्वीकार करती है, पारगमन और विश्राम के दौरान संवेदनशील विशेषताओं को एन्क्रिप्ट करती है, न्यूनतम-विशेषाधिकार पहुंच लागू करती है, अन्वेषक और नीति परिवर्तनों का ऑडिट करती है, लॉग्स को संशोधित (redact) करती है, और नीति अनुमोदन को परिनियोजन (deployment) से अलग करती है। डेटा विलोपन और प्रतिधारण कार्य प्रलेखित पहचानकर्ता मैपिंग द्वारा संचालित होते हैं और ऑडिट योग्य परिणाम उत्पन्न करते हैं। ट्रेनिंग निर्यात एक्सेस-नियंत्रित होते हैं और इनमें रिव्यू नोट्स या भविष्य के परिणामों को फीचर्स के रूप में शामिल नहीं किया जा सकता है।

सत्यापन में शामिल हैं:

• समान और विभिन्न पेलोड के साथ समान decision_id को रीप्ले करना;
• वॉटरमार्क सीमाओं के पार डुप्लिकेट, देर से और आउट-ऑफ-ऑर्डर इवेंट्स भेजना;
• ऐतिहासिक निर्णय समय पर ऑफलाइन और ऑनलाइन फीचर्स की तुलना करना;
• 5,000 रिक्वेस्ट प्रति सेकंड के साथ हॉट एंटिटी कीज़ और कोल्ड-कैश स्टार्ट का लोड टेस्ट करना;
• मॉडल, ऑनलाइन स्टोर, स्ट्रीम प्रोसेसर, एक स्टेट पार्टीशन और रिव्यू सिस्टम को स्वतंत्र रूप से बंद (kill) करना;
• रिव्यू क्षमता को समाप्त करना और कॉन्फ़िगर की गई एडमिशन पॉलिसी को सत्यापित करना;
• जानबूझकर सख्त नियम को शैडो और कैनरी करना, फिर उसे वापस रोल बैक करना;
• फीचर पॉइज़निंग, आइडेंटिफायर फैन-आउट, रीज़न-कोड लीकेज, अनधिकृत पॉलिसी परिवर्तन और रीप्ले दुरुपयोग की जांच करना।

ऑपरेशनल डैशबोर्ड सिस्टम स्वास्थ्य को निर्णय की गुणवत्ता से अलग करते हैं। सिस्टम संकेतों में एंडपॉइंट लेटेंसी, त्रुटियां, डिपेंडेंसी टाइमआउट, फीचर आयु, स्ट्रीम लैग, स्टेट-रीबिल्ड प्रगति, फॉलबैक एक्शन्स और कतार आयु शामिल हैं। परिणाम संकेतों को मैच्योर लेबल्स पर पुनर्गणित किया जाता है और हमेशा उन्हें उत्पन्न करने वाले पॉलिसी और मॉडल वर्जन्स के साथ टैग किया जाता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

“मैं सबसे पहले कॉन्ट्रैक्ट को तय करूँगा। हम औसतन प्रति सेकंड 1,000 पेमेंट्स और पीक पर 5,000 स्कोर करते हैं, p99 पर 100 मिलीसेकंड के भीतर चार में से एक एक्शन लौटाते हैं, और प्रति दिन केवल 10,000 रिव्यू स्वीकार कर सकते हैं। इसका मतलब है कि रिव्यू एक दुर्लभ एक्शन है, मॉडल सटीकता एकमात्र उद्देश्य नहीं है, और पॉलिसी को फ्रॉड लॉस की कीमत फॉल्स ब्लॉक्स और step-up फ्रिक्शन के विरुद्ध तय करनी चाहिए।

पेमेंट सर्विस एक स्थिर डिसीजन आईडी, टोकनाइज़्ड एंटिटी आईडीज़, इवेंट टाइम, राशि और रिक्वेस्ट एट्रिब्यूट्स के साथ POST /v1/risk/decisions को कॉल करती है। एक यूनिक डिसीजन आईडी एक अपरिवर्तनीय रिक्वेस्ट हैश को स्टोर करती है। समान रिक्वेस्ट का अर्थ है रीप्ले; बदले हुए पेलोड का अर्थ है कॉन्फ्लिक्ट। सर्विस वर्ज़न्ड ऑनलाइन फीचर्स को बैच में पढ़ती है और क्रिटिकल प्रति-एंटिटी वेलोसिटी विंडोज़ में वर्तमान प्रयास को आइडेम्पोटेंट रूप से रूप से देखती है। फिर यह हार्ड रूल्स, एक मॉडल और एक हस्ताक्षरित पॉलिसी बंडल का मूल्यांकन करती है। एक्शन लौटाने से पहले निर्णय, रीज़न कोड्स, फीचर फ्रेशनेस, रूल हिट्स, मॉडल और पॉलिसी वर्जन्स और आउटबॉक्स इवेंट कमिट होते हैं।

इवेंट स्ट्रीम ऑनलाइन एग्रीगेट्स को अपडेट करती है और रॉ इतिहास को ऑफलाइन स्टोर करती है। ट्रेनिंग मूल डिसीजन टाइम पर पॉइंट-इन-टाइम जॉइन्स करती है और केवल एक घोषित कटऑफ द्वारा मैच्योर लेबल वर्जन्स को चुनती है। ग्राफ जॉब्स एसिंक्रोनस रहते हैं और कॉम्पैक्ट नेबर-रिस्क फीचर्स पब्लिश करते हैं। प्रत्येक फीचर ग्रुप आयु और उपलब्धता रखता है। यदि कोई मॉडल या क्रिटिकल काउंटर विफल हो जाता है, तो पॉलिसी राशि और पहचान जोखिम का उपयोग करके रूल्स फॉलबैक, step-up, सीमित रिव्यू या ब्लॉक का चयन करती है; यह कभी भी आउटेज को शून्य-जोखिम वैल्यू नहीं मानती है।

मैं ऐतिहासिक रीप्ले, शैडो ट्रैफ़िक और कैनरी ट्रैफ़िक के माध्यम से एक बंडल जारी करूँगा। मैं सार्थक स्लाइस द्वारा फ्रॉड लॉस, फॉल्स पॉजिटिव्स, अप्रूवल और step-up पूर्णता, रिव्यू यील्ड, लेटेंसी, फीचर फ्रेशनेस और फॉलबैक की तुलना करूँगा। डुप्लिकेट रिक्वेस्ट्स और इवेंट्स, लेट डेटा, हॉट कीज़, डिपेंडेंसी आउटेज, रिव्यू सेचुरेशन और एडवरसैरियल फीचर इनपुट्स स्पष्ट टेस्ट्स हैं। यह प्लेटफ़ॉर्म को लो-लेटेंसी, क्षमता-जागरूक और किसी भी निर्णय की व्याख्या करने और पुनरुत्पादन करने में सक्षम बनाता है।”

सामान्य गलतियाँ

• गलती: केवल AUC या सटीकता को अनुकूलित करना और एक थ्रेशोल्ड चुनना। यह क्यों विफल होता है: वे मेट्रिक्स नुकसान के परिमाण,

वैध-ग्राहक फ्रिक्शन, रिव्यू क्षमता और परिचालन विफलताओं को छोड़ देते हैं। समाधान: लागत और क्षमता बाधाओं के साथ एक एक्शन पॉलिसी को परिभाषित करें, फिर परिणाम और अनुभव मेट्रिक्स की निगरानी करें।

• गलती: स्ट्रीम-अपडेटेड काउंटर को पढ़ना और यह मान लेना कि इसमें वर्तमान प्रयास शामिल है। यह क्यों विफल होता है: समवर्ती हमले

समान पुरानी संख्या देख सकते हैं, और पुनः प्रयास दो बार गिन सकते हैं। समाधान: क्रिटिकल वेलोसिटी ऑब्जर्वेशन को प्रति-एंटिटी और आइडेम्पोटेंट बनाएं, और इसके स्टेट वर्ज़न और फ्रेशनेस को रिकॉर्ड करें।

• गलती: अनुपलब्ध फीचर के लिए NULL या शून्य का उपयोग करना। यह क्यों विफल होता है: एक आउटेज एक साधारण कम जोखिम वाला इनपुट बन जाता है।

समाधान: उपलब्धता और आयु को पॉलिसी में शामिल करें और एक परीक्षण किए गए डिग्रेडेशन मैट्रिक्स को लागू करें।

• गलती: ग्लोबल फ्रॉड ग्राफ को सिंक्रोनस रूप से क्वेरी करना। यह क्यों विफल होता है: अप्रत्याशित ट्रैवर्सल और एक बड़ी डिपेंडेंसी

सतह लेटेंसी SLO को तोड़ती है। समाधान: कॉम्पैक्ट ग्राफ फीचर्स को एसिंक्रोनस रूप से पब्लिश करें और मापे गए वृद्धिशील मूल्य के साथ किसी भी ऑनलाइन लुकअप को सही ठहराएं।

• गलती: प्रत्येक गैर-विवादित लेन-देन को तुरंत वैध के रूप में लेबल करना। यह क्यों विफल होता है: परिणाम विलंबित होते हैं और

नवीनतम नकारात्मक उदाहरणों में अपूर्ण अवलोकन विंडो होती हैं। समाधान: लेबल्स को वर्ज़न करें और केवल एक घोषित मैच्योर विंडो पर ट्रेन करें।

• गलती: आज के वेयरहाउस से ऐतिहासिक फीचर्स की पुनर्गणना करना। यह क्यों विफल होता है: देर से और सही किया गया डेटा भविष्य के

ज्ञान को लीक कर सकता है। समाधान: पॉइंट-इन-टाइम जॉइन्स के लिए इवेंट और उपलब्धता समय का उपयोग करें और सर्व किए गए स्नैपशॉट को बनाए रखें।

• गलती: प्रत्येक अनिश्चित मामले को समीक्षा के लिए भेजना। यह क्यों विफल होता है: 10,000 समीक्षाएं दैनिक ट्रैफ़िक के केवल 0.012% को कवर करती हैं।

समाधान: अपेक्षित परिहार्य (avoidable) नुकसान के आधार पर प्राथमिकता दें और कतार प्रवेश और ओवरफ्लो व्यवहार को लागू करें।

• गलती: सीधे सभी ट्रैफ़िक पर एक नियम या मॉडल तैनात करना। यह क्यों विफल होता है: एक तकनीकी रूप से उपलब्ध सेवा अभी भी

बड़े पैमाने पर झूठे ब्लॉक का कारण बन सकती है। समाधान: ऐतिहासिक रीप्ले, शैडो मूल्यांकन, कैनरी स्लाइस, हस्ताक्षरित वर्जन्स और त्वरित रोलबैक।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: एक ही इंस्ट्रूमेंट पर दो समवर्ती प्रयास दोनों सीमा से नीचे की संख्या देखते हैं। क्या बदलता है?

क्रिटिकल नियम को पैसिव कैश्ड एग्रीगेट से हटाकर एक आइडेम्पोटेंट प्रति-एंटिटी ऑब्जर्वेशन में बदलें। स्टेट पार्टीशन उस इंस्ट्रूमेंट के लिए अपडेट्स को ऑर्डर करता है, प्रत्येक डिसीजन आईडी को एक बार रिकॉर्ड करता है, वर्तमान प्रयास को शामिल करता है, और नई संख्या और वर्ज़न लौटाता है। अन्य एंटिटी फीचर्स अंततः कंसिस्टेंट (eventually consistent) रह सकते हैं। लोड टेस्टिंग में एक सिंगल हॉट इंस्ट्रूमेंट शामिल होना चाहिए क्योंकि समान QPS टेस्ट्स इस पार्टीशन अड़चन को उजागर नहीं करेंगे।

फॉलो-अप 2: मॉडल सर्विस पंद्रह मिनट के लिए डाउन है। क्या आप allow करते हैं या block?

वर्ज़न्ड फेलियर मैट्रिक्स का उपयोग करें। हार्ड ब्लॉकलिस्ट और क्रिटिकल वेलोसिटी रूल्स जारी रहते हैं। विश्वसनीय पहचान वाला एक कम मूल्य का भुगतान केवल-रूल्स allow का उपयोग कर सकता है; एक नया-डिवाइस या उच्च-मूल्य का भुगतान step up कर सकता है, सीमित रिव्यू कतार में प्रवेश कर सकता है, या block हो सकता है। सभी फॉलबैक एक्शन्स में एक डिग्रेडेशन रीज़न होता है। डिपेंडेंसी रिकवरी और व्यावसायिक प्रभाव दोनों की निगरानी करें; चुपचाप डिफ़ॉल्ट स्कोर प्रदान न करें।

फॉलो-अप 3: चार्ज-बैक लेबल्स में हफ्तों लगते हैं, लेकिन एक नया अभियान आज शुरू होता है। आप कैसे अनुकूलित होते हैं?

जांच के लिए ऑथेंटिकेशन विफलता, एनालिस्ट निर्णय, मर्चेंट रिपोर्ट और केंद्रित शेयर्ड-एंटिटी पैटर्न जैसे प्रमुख संकेतों का उपयोग करें, जबकि उनके प्रोवेनेंस को मैच्योर लेबल्स से अलग रखें। शैडो और कैनरी चरणों के माध्यम से एक संकीर्ण प्रतिवर्ती नियम तैनात करें। केवल तभी पुन: प्रशिक्षित (retrain) करें जब चुने गए लेबल परिभाषा में पर्याप्त मैच्योर कवरेज हो; अन्यथा नवीनतम स्पष्ट रूप से वैध उदाहरण मूल्यांकन को पक्षपाती बनाते हैं।

फॉलो-अप 4: रिव्यू की मांग बढ़कर प्रति दिन 50,000 मामलों तक पहुंच जाती है जबकि क्षमता 10,000 ही रहती है। क्या होता है?

अपेक्षित परिहार्य नुकसान, साक्ष्य गुणवत्ता, राशि और समय संवेदनशीलता के आधार पर मामलों को रैंक करें; आवश्यक सेगमेंट के लिए क्षमता आरक्षित करें और केवल शीर्ष 10,000 को प्रवेश दें। शेष बैंड पूर्व-स्वीकृत step-up, allow, या block पॉलिसी का पालन करता है। कतार आयु और एनालिस्ट थ्रूपुट को ट्रैक करें। निष्पादन योग्य सेवा स्तर के बिना कतार में संदेश जोड़ना केवल अधिभार (overload) को छुपाता है।

फॉलो-अप 5: ऑनलाइन फीचर स्टोर को ही ट्रेनिंग का एकमात्र स्रोत क्यों न बनाया जाए?

यह लो-लेटेंसी रीड्स के लिए नवीनतम वैल्यूज को बनाए रखता है और आमतौर पर यह पुनर्निर्माण नहीं कर सकता कि लाखों ऐतिहासिक निर्णय समय पर क्या ज्ञात था। ट्रेनिंग के लिए टाइम-सीरीज़ इतिहास, पॉइंट-इन-टाइम जॉइन्स, बैकफ़िल्स और बड़े स्कैन की आवश्यकता होती है। एक ही इंजन को परस्पर विरोधी वर्कलोड्स को सर्व करने के लिए मजबूर करने के बजाय अलग-अलग ऑनलाइन और ऑफलाइन स्टोर्स में साझा फीचर डेफिनिशन्स और पैरिटी टेस्ट्स का उपयोग करें।

फॉलो-अप 6: कुछ भुगतानों की अनुमति दिए जाने के बाद एक ग्राफ जॉब को फ्रॉड रिंग का पता चलता है। क्या आप उन निर्णयों को फिर से लिख सकते हैं?

नहीं। मूल कार्रवाई और सटीक प्रोवेनेंस को सुरक्षित रखें। इसके अवलोकन समय के साथ एक नया निष्कर्ष या लेबल वर्ज़न जोड़ें, अनुमत डाउनस्ट्रीम कार्रवाई करें, भविष्य के निर्णयों के लिए ऑनलाइन एंटिटी जोखिम को अपडेट करें, और मामले को रीप्ले में शामिल करें। पुराने निर्णय को फिर से लिखने से वह मिट जाएगा जो सर्विस वास्तव में जानती थी और ऑडिट व मॉडल मूल्यांकन टूट जाएगा।