डेटा इंजीनियरिंग साक्षात्कार: आप एक ऑडिट करने योग्य डिस्ट्रिब्यूटेड डेटा-डिलीशन पाइपलाइन कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

यह प्रश्न परीक्षण करता है कि क्या एक डेटा इंजीनियर एकल डिलीशन अनुरोध को एक क्रॉस-सिस्टम, पुनः प्रयास करने योग्य (retryable), और ऑडिट योग्य जीवनचक्र में बदल सकता है। डिलीशन केवल प्राइमरी डेटाबेस DELETE से कहीं अधिक है; इसमें डिराइव्ड टेबल, कैश, इंडेक्स, इवेंट लॉग, बैकअप और प्रोसेसर शामिल हैं। डिस्कवरी, आइडेंटिटी मैपिंग, लीगल होल्ड, इडेम्पोटेंसी, रिकवरी और पूर्णता के प्रमाण को कवर करें।

साक्षात्कारकर्ता क्या परीक्षण करता है

मजबूत उत्तर दायरे और अपवादों को परिभाषित करते हैं, फिर स्वामियों (owners) के साथ एक डेटा कैटलॉग बनाते हैं। एक वर्कफ़्लो डिपेंडेंसीज़ के साथ डिलीट या एनोनिमाइज़ कमांड भेजता है और रसीदों (receipts) की प्रतीक्षा करता है। स्टेट्स एक इम्यूटिएबल ऑडिट ट्रेल के साथ requested, running, verified, और blocked के बीच अंतर करती हैं। यदि भौतिक बैकअप को तुरंत संपादित नहीं किया जा सकता है, तो एन्क्रिप्शन इरेज़र, एक्सपायरी, रिस्टोर आइसोलेशन और पुनः लागू करने की व्याख्या करें।

स्पष्ट करने के लिए प्रश्न

• व्यक्ति की पहचान क्या करती है, और ईमेल, डिवाइस, ऑर्डर और अज्ञात पहचानकर्ता (anonymous identifiers) कैसे जुड़े हैं?
• किन रिकॉर्ड्स को गायब होना चाहिए, और किन चालानों (invoices), धोखाधड़ी के सबूतों या लीगल होल्ड को अस्थायी रूप से बने रहना चाहिए?
• क्या सर्च इंडेक्स, कैश, एग्रीगेट्स, इवेंट लॉग, ऑब्जेक्ट स्टोरेज, बैकअप और SaaS प्रोसेसर शामिल हैं?
• क्या लक्ष्य भौतिक डिलीशन, अपरिवर्तनीय एनोनिमाइज़ेशन, या एक निश्चित समय सीमा के भीतर उपयोग को रोकना है?
• पूर्णता, टाइमआउट, मानव समीक्षा और यूज़र रसीद को क्या परिभाषित करता है?

30-सेकंड का उत्तर ढांचा

“मैं सिस्टम, फ़ील्ड, स्वामियों, रिटेंशन नियमों और डिलीशन क्षमताओं को कैटलॉग करूँगा। प्रत्येक अनुरोध एक इम्यूटिएबल डिलीशन केस और इडेम्पोटेंट कार्य बनाता है। ऑर्केस्ट्रेटर डिपेंडेंसीज़ के साथ डिलीट, एनोनिमाइज़, या कुंजी-मिटाने (key-erasure) के कमांड भेजता है; प्रत्येक उपभोक्ता दायरा, वर्ज़न और एक सत्यापन सारांश लौटाता है। विफलताओं का पुनः प्रयास किया जाता है या उन्हें एस्केलेट किया जाता है। लीगल-होल्ड डेटा को रिकॉर्ड किए गए अपवाद के साथ एक्सेस-फ़्रीज़ किया जाता है और होल्ड समाप्त होने पर डिलीट कर दिया जाता है। पूर्णता के लिए कैटलॉग कवरेज, रसीदें, सैंपल रीड्स और एक ऑडिट ट्रेल की आवश्यकता होती है; यूज़र को आंतरिक टोपोलॉजी के बिना ईमानदार स्थिति प्राप्त होती है।”

चरण-दर-चरण विस्तृत उत्तर

चरण 1: एक डेटा और आइडेंटिटी मैप बनाएं

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

चरण 2: डिलीशन नीति परिभाषित करें

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

चरण 3: एक इडेम्पोटेंट केस बनाएं

case_id, विषय आईडी, नीति वर्ज़न, समय सीमा और स्रोत बनाएं। प्रत्येक लक्ष्य केस आईडी प्राप्त करता है और दोहराव पर वही परिणाम लौटाता है। Requested, running, verified, blocked, failed, और expired जैसी स्थितियों का उपयोग करें।

चरण 4: डिपेंडेंसीज़ के साथ प्रोपेगेट करें

स्रोत रिकॉर्ड हटाएं या एक टॉम्बस्टोन (tombstone) उत्सर्जित करें, फिर इंडेक्स, कैश और डिराइव्ड वेयरहाउस के लिए CDC उपभोक्ताओं को ट्रिगर करें। बैच सिस्टम को एक सेप्रेशन टेबल (suppression table) की आवश्यकता होती है ताकि बाद के जॉब विषय को फिर से न बनाएं। तृतीय पक्ष एक API रसीद या संविदात्मक प्रक्रिया के माध्यम से पुष्टि करते हैं।

चरण 5: बैकअप और कुंजी मिटाने को संभालें

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

चरण 6: सफलता कोड से परे सत्यापित करें

उपभोक्ता काउंट, वर्ज़न, विभाजन (partitions) और चेकसम लौटाते हैं। ऑर्केस्ट्रेटर प्राइमरी स्टोर, इंडेक्स, वेयरहाउस और ऑब्जेक्ट स्टोर में सैंपल्ड रीड्स लेता है, और कैश अमान्यता और CDC वॉटरमार्क की जांच करता है। विफल सत्यापन केस को बंद करने के बजाय क्षतिपूर्ति कार्य (compensating work) बनाता है।

चरण 7: रिटेंशन अपवादों को अलग करें

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

चरण 8: ऑडिट, अलर्ट और प्रतिक्रिया

ऑडिट लॉग में संवेदनशील पेलोड के बजाय अपरिवर्तनीय विषय डाइजेस्ट, कर्ता (actor), समय, नीति वर्ज़न और परिणाम होते हैं। केस की आयु, विफलता दर, कैटलॉग कवरेज, तृतीय-पक्ष रसीदें और रिस्टोर ड्रिल की निगरानी करें। यूज़र्स स्पष्ट समय सीमा के साथ completed, processing, या legally held स्थिति देखते हैं।

डिलीशन वर्कफ़्लो स्यूडोकोड

case = create_case(subject, policy_version)
for target in catalog.targets(subject, policy_version):
    enqueue_idempotent(case.id, target, action_for(target))
verify_samples(case)
close(case, "verified" if all_verified(case) else "blocked")

ट्रेड-ऑफ़ और सीमाएं

प्रमाण में यह शामिल होना चाहिए कि सिस्टम ने कहाँ देखा, किन लक्ष्यों ने पावती दी, और कौन से अपवाद बने रहे। इसे गैर-सत्यापन योग्य भौतिक गायब होने का वादा नहीं करना चाहिए। Google Cloud डिलीशन को एक चरणबद्ध पाइपलाइन के रूप में वर्णित करता है जिसमें चरण पूरे होने तक डेटा सुरक्षित रहता है।

रोलआउट योजना और साक्ष्य

एक यूज़र डेटासेट चुनें और एक कैटलॉग, आइडेंटिटी मैप, प्राइमरी स्टोर, इंडेक्स और वेयरहाउस कनेक्ट करें। डुप्लिकेट संदेश, ऑफ़लाइन उपभोक्ता, बैकअप रिस्टोर और नीति परिवर्तन इंजेक्ट करें। यूरोपीय आयोग (European Commission) इरेज़र के कानूनी अपवादों का दस्तावेजीकरण करता है; Google Cloud चरणबद्ध डिलीशन का दस्तावेजीकरण करता है; TechInterview का सार्वजनिक डिज़ाइन प्रश्न माइक्रोसर्विसेज, ऑब्जेक्ट स्टोरेज, एनालिटिक्स, बैकअप और ऑडिट ट्रेल्स की मांग करता है।

पायलट निकास मानदंड

कैटलॉग कवरेज मापने योग्य है; प्रत्येक लक्ष्य का एक स्वामी और क्षमता है; दोहराए गए अनुरोध इडेम्पोटेंट हैं; विफलताओं का पुनः प्रयास किया जाता है या उन्हें एस्केलेट किया जाता है; सैंपल्ड सत्यापन अवशिष्ट (residuals) पाता है; होल्ड का एक आधार और समाप्ति है; और यूज़र रसीद आंतरिक स्थिति से मेल खाती है।

यह कैसे साबित करें कि लाभ वास्तविक है

पहले और बाद के अपंजीकृत डेटासेट, पूर्णता समय, सत्यापन द्वारा पाई गई अवशिष्ट दर, पुनः प्रयास दर और मानवीय हस्तक्षेप की तुलना करें। केवल सुखद मार्ग (happy path) को मापने के बजाय ऑफ़लाइन उपभोक्ताओं, बैकअप रिस्टोर और तृतीय-पक्ष टाइमआउट का अभ्यास करें।

सामान्य गलतियाँ और अनुवर्ती प्रश्न

केवल प्राइमरी पंक्ति को हटाना

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

प्रत्येक सिस्टम के लिए एक वैश्विक DELETE इवेंट

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

यह दावा करना कि बैकअप तुरंत मिटा दिए जाते हैं

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

लीगल होल्ड सभी डिलीशन को अवरुद्ध करने से कैसे बचते हैं?

होल्ड किए गए दायरे को कम करें, पहुंच को फ्रीज करें, आधार, स्वामी और समीक्षा तिथि रिकॉर्ड करें, और होल्ड के बाहर सब कुछ हटाना जारी रखें।

आप डेटा को फिर से बनने से कैसे रोकते हैं?

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

यदि यूज़र तत्काल पूर्णता की मांग करता है तो क्या होगा?

सत्यापित लक्ष्यों को समयबद्ध बैकअप या तृतीय-पक्ष चरणों से अलग करें, प्रोसेसिंग स्थिति और एक समय सीमा लौटाएं, और कभी भी पूर्ण किए गए भौतिक इरेज़ का आविष्कार न करें।