आप एक प्राइवेसी-प्रिजर्विंग प्रोडक्ट टेलीमेट्री और एनालिटिक्स प्लेटफॉर्म कैसे डिज़ाइन करेंगे?

1. प्रॉम्प्ट

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

एक प्राइवेसी-प्रिजर्विंग टेलीमेट्री और एनालिटिक्स प्लेटफ़ॉर्म डिज़ाइन करें। इसमें क्लाइंट कलेक्शन सीमाएं, इवेंट फॉर्मेट, एनोनिमाइज़ेशन या लोकल रैंडमाइज़ेशन, सेंट्रल डिफरेंशियल प्राइवेसी, यूज़र-लेवल कंट्रीब्यूशन लिमिट्स, बजट और क्वेरी APIs, विश्वसनीयता, डिलीशन रिक्वेस्ट, अनुमतियां (परमिशन) और सत्यापन शामिल होने चाहिए। स्पष्ट रूप से बताएं कि कौन सी समस्याएं केवल किसी ID को हैश करने से हल नहीं की जा सकती हैं।

2. बाधाएं और स्पष्टीकरण

• प्रत्येक इवेंट को एक स्वतंत्र व्यक्ति मानने के बजाय प्राइवेसी यूनिट के रूप में उपयोगकर्ता या डिवाइस को प्राथमिकता दें; साझा किए गए डिवाइसों और मल्टी-डिवाइस उपयोगकर्ताओं के बारे में बताएं।
• केवल रजिस्टर्ड इवेंट नाम, वर्शन, मोटा क्षेत्र (coarse region), परफॉर्मेंस बकेट्स और आवश्यक एरर श्रेणियां ही एकत्र करें। रॉ (raw) URLs, फ्री टेक्स्ट, पूरे IP पते, सटीक स्थान या कंटेंट पेलोड एकत्र न करें।
• स्मॉल-ग्रुप सप्रेशन, डिफरेंशियल-प्राइवेसी बजट और ट्रेसेबल क्वेरी ऑडिट के साथ कम से कम 24 घंटे की विंडो में आंकड़े जारी करें।
• डेटा का नुकसान (लॉस) और देरी स्वीकार्य हैं, लेकिन पुनः प्रयासों (retries), कैश और रेप्लिकस द्वारा किसी एक उपयोगकर्ता के योगदान को असीमित रूप से नहीं बढ़ाया जाना चाहिए।

3. हाई-लेवल आर्किटेक्चर और डेटा फ्लो

क्लाइंट SDK टेलीमेट्री कतार (queue) में वर्शन वाले बैच लिखने से पहले एक इवेंट अनुमति सूची (allowlist), फील्ड क्लिपिंग, वैल्यू बाउंड्स और लोकल सैंपलिंग लागू करता है। इनजेशन गेटवे एनालिटिक्स कुंजी (key) के रूप में अकाउंट टोकन का उपयोग किए बिना सिग्नेचर, साइज, टाइम विंडो और रेट की पुष्टि करता है। स्ट्रीम प्रोसेसिंग यूज़र-लेवल डिडुप्लिकेशन, कंट्रीब्यूशन कैप्स, विंडो एग्रीगेशन और एनोमली फ़िल्टरिंग करती है। एक अल्पकालिक (short-lived) रॉ बफर का सख्त TTL होता है; लॉन्ग-टर्म स्टोर केवल सुरक्षित एग्रीगेट इंटरमीडिएट रखता है।

client SDK
  -> schema/allowlist + local sampling + coarse buckets
  -> encrypted batch with rotating upload token
  -> ingestion gateway (auth, size, rate, replay checks)
  -> stream buffer
  -> privacy transform (user contribution cap, clipping, optional local noise)
  -> aggregate store
  -> DP query service (budget, minimum group, audit)
  -> dashboards and export API

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

4. डेटा मॉडल, मिनिमाइज़ेशन और डिडुप्लिकेशन

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

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

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

5. प्राइवेसी बजट, विश्वसनीयता और क्वेरी APIs

क्वेरी सर्विस प्राइवेसी यूनिट, डेटासेट और टाइम विंडो के आधार पर एप्सिलॉन/डेल्टा (epsilon/delta) बजट को ट्रैक करती है। प्रत्येक आधिकारिक क्वेरी बजट, न्यूनतम ग्रुप साइज़ और अनुमत आयामों (dimensions) की जांच करती है, फिर एक वर्शन वाले एग्रीगेट टेबल से एक नॉइज़ी परिणाम उत्पन्न करती है और एक ऑडिट प्रविष्टि रिकॉर्ड करती है। उसी लॉजिकल क्वेरी के पुनः प्रयास पर एक इडेम्पोटेंट परिणाम वापस आना चाहिए या केवल एक बार शुल्क लिया जाना चाहिए; फ़िल्टर आयाम जोड़ने से अतिरिक्त बजट खर्च हो सकता है।

अपलोड्स एट-लीस्ट-वन्स डिलीवरी (at-least-once delivery) का उपयोग करते हैं। क्लाइंट बैच पुनः प्रयास कर सकते हैं, गेटवे बैच टोकन द्वारा डिडुप्लिकेट करता है, और स्ट्रीम प्रोसेसिंग उपयोगकर्ता और टाइम बकेट द्वारा डिडुप्लिकेट करती है, जबकि अपुष्ट लेट इवेंट्स को अलग करती है। लॉस, डिले और सैंपलिंग रेट डेटा-क्वालिटी मेट्रिक्स से संबंधित हैं; अन्यथा डैशबोर्ड में गिरावट को प्रोडक्ट व्यवहार में बदलाव के रूप में गलत समझा जा सकता है।

20 मिलियन डिवाइसों और प्रति डिवाइस प्रति दिन अधिकतम 200 इवेंट्स पर, सैद्धांतिक ऊपरी सीमा प्रति दिन 4 बिलियन इवेंट्स है। डिज़ाइन में वर्शन रोलआउट, क्रैश स्टॉर्म और रीप्ले के लिए पर्याप्त गुंजाइश के साथ सैंपलिंग, बैच कम्प्रेशन और पार्टीशन्ड स्टोरेज का उपयोग करना चाहिए। क्वेरी लेयर को हाई-कार्डिनैलिटी स्लाइस, समवर्ती (concurrent) निर्यात और क्रॉस-विंडो जॉइन्स को सीमित करना चाहिए ताकि बजट और कंप्यूट एक साथ समाप्त न हों।

6. फॉलो-अप्स और संभावित जाल (Traps)

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

7. सत्यापन और परिचालन मेट्रिक्स

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

8. इंटरव्यू स्कोरिंग बिंदु

प्राइवेसी सीमाएं और डेटा प्रवाह खींचने में सक्षम हों

उम्मीदवार को यह स्पष्ट करना चाहिए कि क्लाइंट, गेटवे, शॉर्ट-लाइव्ड बफर, एग्रीगेशन लेयर और क्वेरी लेयर किस पर भरोसा करते हैं, क्या बनाए रखते हैं और क्या हटाते हैं।

यूज़र-लेवल कंट्रीब्यूशन नियंत्रण लागू करने में सक्षम हों

उन्हें केवल "इसे एनोनिमाइज़ करें" लिखने के बजाय यूज़र/विंडो डिडुप्लिकेशन, कंट्रीब्यूशन कैप्स, क्लिपिंग, बैच इडेम्पोटेंसी और लेट इवेंट्स को शामिल करना चाहिए।

बजट और विश्वसनीयता को एक साथ डिज़ाइन करने में सक्षम हों

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

मात्रात्मक सत्यापन प्रदान करने में सक्षम हों

उन्हें प्रति दिन 4-बिलियन-इवेंट्स की ऊपरी सीमा का उपयोग करना चाहिए और केवल घटकों को सूचीबद्ध करने के बजाय प्राइवेसी, डेटा-क्वालिटी, विश्वसनीयता और दुरुपयोग परीक्षणों का प्रस्ताव देना चाहिए।