डेटा इंजीनियरिंग इंटरव्यू: आप राइट-टू-इरेज़र (राइट टू बी फॉरगॉटन) डेटा डिलीशन पाइपलाइन कैसे डिज़ाइन करेंगे?

प्रश्न और संदर्भ

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

मान लें कि एक गोपनीयता (privacy) या कानूनी सेवा ने अनुरोधकर्ता को पहले ही सत्यापित कर दिया है, अनुरोध को मंजूरी दे दी है, इसके दायरे को परिभाषित किया है, किसी भी लागू अपवाद को दर्ज किया है, और एक नीतिगत समय सीमा (policy deadline) प्रदान की है। डेटा प्लेटफ़ॉर्म उस निर्णय को निष्पादित करता है। इंटरव्यू में इंजीनियर से कानून की व्याख्या करने के लिए नहीं कहा जाता है।

नीति की सीमा को स्पष्ट रखें। GDPR Article 17 इरेज़र के अधिकार को परिभाषित करता है और शर्तों तथा अपवादों को भी सूचीबद्ध करता है, इसलिए एक स्वीकृत अनुरोध के लिए एक दर्ज दायरे की आवश्यकता होती है। Article 19 प्राप्तकर्ताओं को संचार की आवश्यकता हो सकती है। लाइव सिस्टम, बैकअप और वर्ज़न वाली टेबल भी अलग-अलग डिलीशन अवस्थाओं को उजागर करती हैं: बैकअप डेटा ओवरराइट होने तक बना रह सकता है जबकि उसे उपयोग से बाहर (beyond use) कर दिया जाता है, और एक हटाई गई Iceberg पंक्ति पुराने स्नैपशॉट द्वारा संदर्भित फ़ाइल में बनी रह सकती है। वर्कफ़्लो को उन अवस्थाओं को केवल एक डेटाबेस प्रतिक्रिया में समेटने के बजाय उनका सटीक प्रतिनिधित्व करना चाहिए।

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

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

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

दूसरा, क्या उम्मीदवार वास्तविक डेटा मॉडल में किसी व्यक्ति का पता लगा सकता है? एक ईमेल पता शायद ही कभी पर्याप्त होता है। एक ही व्यक्ति के पास खाता ID, टेनेंट-दायरे वाली ID, डिवाइस ID, भुगतान-ग्राहक ID, सपोर्ट पहचान और खाता विलय (merge) के दौरान बदले गए पहचानकर्ता हो सकते हैं। एक मजबूत उत्तर एक नियंत्रित पहचान-समाधान (identity-resolution) चरण प्रस्तुत करता है और ऐसे साझा रिकॉर्ड पर विचार करता है जो एक से अधिक व्यक्तियों से संबंधित हैं।

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

चौथा, क्या वर्कफ़्लो पुनः प्रयासों (retries) और रुकावटों (outages) से बच सकता है? एक सिंक्रोनस अनुरोध जो हर सिस्टम में फ़ैन-आउट होता है, टाइम आउट हो जाएगा और अस्पष्ट आंशिक स्थिति छोड़ देगा। इंटरव्यूअर टिकाऊ स्थिति, आइडेम्पोटेंट टारगेट कार्य, सीमित पुनः प्रयास, स्वामित्व, समय सीमा, और पुन: प्रयास करने योग्य विफलता, प्रलेखित प्रतिधारण (retention), छूट और स्थायी कार्यान्वयन अंतराल के बीच अंतर करने के तरीके की अपेक्षा करता है।

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

पूछे जाने वाले स्पष्टीकरण प्रश्न

वास्तव में क्या अनुमोदित किया गया है? कौन सा विषय, क्षेत्राधिकार, डेटा उद्देश्य, समय सीमा, उत्पाद और कानूनी अपवाद दायरे में हैं? अंतिम नीति निर्णय का मालिक कौन है?
विषय कुंजी (subject key) क्या है? क्या कोई स्थिर आंतरिक विषय ID है? इसे किन ऐतिहासिक उपनामों, विलय किए गए खातों, टेनेंट ID, डिवाइस ID और बाहरी प्रोसेसर ID को हल करना होगा?
कौन से रिकॉर्ड साझा किए गए हैं? ऑर्डर, बातचीत, संगठनात्मक रिकॉर्ड, धोखाधड़ी के सबूत या वित्तीय लेनदेन कई लोगों को संदर्भित कर सकते हैं या उनकी एक स्वीकृत प्रतिधारण आवश्यकता हो सकती है। दूसरे व्यक्ति के रिकॉर्ड को दूषित किए बिना किन फ़ील्ड्स को मिटाया जा सकता है?
डेटा इन्वेंट्री क्या है? क्या सभी स्टोर एक मालिक, विषय लोकेटर, डिलीशन मोड, लाइनेज, प्रतिधारण व्यवहार, सत्यापनकर्ता और रीस्टोर प्रक्रिया घोषित करते हैं? अपंजीकृत संपत्तियों का पता कैसे लगाया जाता है?
कौन से स्टोर म्यूटेबल हैं? क्या इवेंट लॉग और ऑब्जेक्ट फ़ाइलों को फिर से लिखा जा सकता है? लॉजिकल डिलीट के बाद कौन से लेकहाउस स्नैपशॉट और वेयरहाउस टाइम-ट्रैवल वर्ज़न क्वेरिएबल रहते हैं?
बैकअप के लिए पूर्णता क्या मानी जाती है? क्या बैकअप को चुनिंदा रूप से फिर से लिखा जा सकता है, क्या इसे पुराना होकर समाप्त होना चाहिए, या इसे उपयोग से बाहर प्रतिबंधित किया जा सकता है? रीस्टोर की गई सेवाओं द्वारा ट्रैफ़िक स्वीकार करने से पहले एक पुराने बैकअप को कैसे सुरक्षित बनाया जाता है?
क्या कटऑफ़ के बाद नया डेटा आ सकता है? क्या खाता बंद करने से नई गतिविधि ब्लॉक हो जाती है? क्या विलंबित इवेंट्स, CDC पुनः प्रयास, आयात, या फिर से बनाया गया खाता पुराने पहचानकर्ता का उपयोग कर सकता है?
किन प्रोसेसरों को डेटा प्राप्त हुआ? क्या कोई API, टिकट या अनुबंधीय पुष्टिकरण पथ है? उनके टारगेट कार्य के अंतिम स्थिति में पहुंचने से पहले किस साक्ष्य की आवश्यकता होती है?
समय सीमा और एस्केलेशन के नियम क्या हैं? कौन सी विफलताएं किसी मालिक को पेज करती हैं, अनुरोध कब अतिदेय (overdue) हो जाता है, और कौन एक प्रलेखित अपवाद को मंजूरी दे सकता है?
सत्यापन डेटा लीक होने से कैसे रोकेगा? क्या प्रोब लॉग में व्यक्तिगत मानों की प्रतिलिपि बनाने के बजाय काउंट, स्नैपशॉट ID और सॉल्टेड साक्ष्य वापस कर सकते हैं?

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

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

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

चरण 1: पाइपलाइन निष्पादन से नीतिगत निर्णय को अलग करें

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

स्पष्ट स्थितियों का उपयोग करें जैसे received, authorized, planned, executing, verifying, completed, partially completed, rejected, और overdue। स्थिति परिवर्तन अपेंड-ओनली और उत्तरदायी (attributable) होते हैं। कोई अनुरोध केवल तभी समाप्त हो सकता है जब स्वीकृत टारगेट मेनिफ़ेस्ट के प्रत्येक आइटम का एक अनुमत अंतिम परिणाम हो: erased, dated expiry तक उपयोग से परे (rendered beyond use), प्रोसेसर द्वारा पुष्टि की गई, या एक प्रलेखित अपवाद द्वारा कवर किया गया।

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

चरण 2: पहचान को एक बार हल करें और इतिहास को सुरक्षित रूप से संरक्षित करें

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

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

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

चरण 3: इन्वेंट्री और लाइनेज से एक टारगेट मेनिफ़ेस्ट जेनरेट करें

प्रत्येक डेटा संपत्ति जो विषय डेटा रख सकती है, उसे एक डिलीशन अनुबंध पंजीकृत करना चाहिए:

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

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

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

चरण 4: एक टिकाऊ, आइडेम्पोटेंट वर्कफ़्लो निष्पादित करें

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

टारगेट स्थिति को स्वतंत्र रूप से बनाए रखें: pending, running, retryable failure, blocked, erased, restricted until expiry, processor pending, exception, और verification failed। क्षणिक त्रुटियों के लिए बाउंडेड एक्सपोनेंशियल बैकऑफ़ का उपयोग करें, समाप्त प्रयासों के लिए डेड-लेटर या ब्लॉक स्थिति, और मालिक को दिखाई देने वाली समय सीमा का उपयोग करें। एक आंशिक रुकावट को सफल डिलीशन को वापस (roll back) नहीं करना चाहिए।

ऑर्केस्ट्रेटर को सभी स्टोरों में वितरित लेनदेन (distributed transaction) नहीं रखना चाहिए। यह एक सागा (saga) की तरह व्यवहार करता है जिसके अग्रिम कार्य स्वीकृत अंतिम स्थिति पर अभिसरण करते हैं। क्षतिपूर्ति का अर्थ आमतौर पर अलग प्राधिकरण के तहत सत्य के संरक्षित स्रोत से एक अत्यधिक व्यापक रिडैक्शन को सही करना है, न कि पहले से मिटाए गए सभी डेटा को रीस्टोर करना।

चरण 5: प्रत्येक स्टोरेज वर्ग के लिए डिलीशन कार्रवाई चुनें

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

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

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

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

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

थर्ड-पार्टी प्रोसेसर। प्रोसेसर के समर्थित चैनल का उपयोग करके स्कोप्ड अनुरोध भेजें, एक स्थिर आइडेम्पोटेंसी संदर्भ संलग्न करें, और पावती (acknowledgment) और पूर्णता स्थिति बनाए रखें। GDPR का Article 19 लागू मामलों में प्राप्तकर्ताओं को संचार को कवर करता है। भेजा गया ईमेल पूर्णता का प्रमाण नहीं है जब अनुबंध एक मशीन-पठनीय पुष्टिकरण या टिकट स्थिति प्रदान करता है।

चरण 6: एग्रीगेट्स, मॉडल और एनोनिमाइज़ेशन को सोच-समझकर संभालें

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

की-युक्त या छोटे-समूह (small-cohort) एग्रीगेट्स के लिए, अनुमत स्रोत रिकॉर्ड से प्रभावित विभाजन को फिर से बनाएं। घटाव (subtraction) केवल पर्याप्त रूप से बनाए रखे गए योगदान मेटाडेटा वाले इनवर्टिबल मेट्रिक्स के लिए काम करता है। पर्सेंटाइल, स्केच, प्रशिक्षित एम्बेडिंग और कई मॉडल आर्टिफ़ैक्ट्स एक पंक्ति को घटाकर सुरक्षित रूप से ठीक नहीं किए जा सकते हैं। एक प्रलेखित पुनर्निर्माण, पुनर्शिक्षण (retraining) नीति, या स्वीकृत एनोनिमाइज़ेशन निर्णय चुनें।

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

चरण 7: रेस, रीप्ले और रीस्टोर से पुनर्जीवन को रोकें

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

समवर्ती इनजेशन के विरुद्ध डिलीशन का क्रम निर्धारित करें। जहां संभव हो विषय कुंजी द्वारा कार्य को विभाजित करें, या स्रोत वॉटरमार्क रिकॉर्ड करें और सभी लेखकों (writers) के कटऑफ़ पार करने के बाद एक अंतिम स्कैन दोहराएं। अलग से तय करें कि अनुरोध के बाद वास्तव में नई, अधिकृत गतिविधि को कैसे संभाला जाता है। एक पुराना इवेंट रीप्ले दबा दिया जाता है; वैध उत्पाद उद्देश्य के तहत एक नया खाता बनाने वाले व्यक्ति को स्थायी वैश्विक ब्लॉकिंग के बजाय एक नए विषय युग (subject epoch) की आवश्यकता हो सकती है।

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

चरण 8: स्वतंत्र साक्ष्य के साथ पूर्णता सत्यापित करें

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

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

काउंट और अपारदर्शी कुंजियों के साथ जांचें। हटाए गए मानों को साक्ष्य स्टोर में कॉपी करने से बचें। नमूना-आधारित जांच पूर्ण किए जा रहे अनुरोध के लिए नियतात्मक (deterministic) जांचों की जगह नहीं ले सकती बल्कि केवल उनकी पूरक हो सकती है।

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

चरण 9: मापने योग्य दायित्वों के साथ सिस्टम का संचालन करें

नीतिगत समय सीमा, अतिदेय और आंशिक रूप से पूर्ण किए गए अनुरोधों, टारगेट सफलता और पुन: प्रयास दरों, मेनिफ़ेस्ट कवरेज, अज्ञात संपत्तियों, प्रोसेसर पुष्टिकरण विलंबता, स्नैपशॉट और बैकअप समाप्ति बैकलॉग, रीप्ले-पुनर्जीवन की घटनाओं और रीस्टोर पुन: अनुप्रयोग सफलता के विरुद्ध अनुरोध पूर्णता समय को ट्रैक करें।

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

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

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

"मैं केवल एक अधिकृत अनुरोध लिफाफा प्राप्त करूँगा: अनुरोध ID, अपारदर्शी विषय संदर्भ, स्वीकृत दायरा, कटऑफ़, समय सीमा, नीति वर्ज़न और अपवाद संदर्भ। एक प्रतिबंधित पहचान सेवा उस विषय को वर्ज़न वाले आंतरिक, ऐतिहासिक, टेनेंट, डिवाइस और प्रोसेसर ID में विस्तारित करती है। यह एक ईमेल पते को शाश्वत प्राथमिक कुंजी के रूप में उपयोग नहीं करती है।

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

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

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

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

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

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

मेरे परिचालन मेट्रिक्स में समय सीमा अनुपालन, आंशिक और अतिदेय गणना, कैटलॉग कवरेज, अज्ञात टारगेट, रीप्ले पुनर्जीवन, स्नैपशॉट और बैकअप समाप्ति बैकलॉग, प्रोसेसर विलंबता और रीस्टोर पुन: अनुप्रयोग सफलता शामिल होगी। यह डिज़ाइन कंपनी को सामान्य लॉग से व्यक्तिगत मानों को बाहर रखते हुए और डेटा पाइपलाइन के बाहर कानूनी दायरे के निर्णयों को रखते हुए एक टिकाऊ सबूत का निशान (proof trail) देता है।"

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

केवल प्राथमिक खाता पंक्ति को हटाना → प्रतियां इंडेक्स, विश्लेषणात्मक तालिकाओं, निर्यातों और प्रोसेसरों में बनी रहती हैं → एक लाइनेज-समर्थित टारगेट मेनिफ़ेस्ट उत्पन्न करें और प्रत्येक आवश्यक सर्विंग और स्टोरेज सतह को सत्यापित करें।
ईमेल को सार्वभौमिक विषय कुंजी के रूप में उपयोग करना → ईमेल बदलते हैं, पुन: उपयोग किए जा सकते हैं, और विलय की गई या बाहरी पहचानों को छोड़ देते हैं → स्रोत-इतिहास के साथ एक वर्ज़न वाले पहचान ग्राफ़ के माध्यम से एक सत्यापित विषय को हल करें।
अनुरोध API से एक सिंक्रोनस फ़ैन-आउट को कॉल करना → एक टाइमआउट अज्ञात आंशिक स्थिति और असुरक्षित पुन: प्रयास बनाता है → टिकाऊ प्रति-टारगेट कार्यों, स्पष्ट स्थितियों, आइडेम्पोटेंसी, और मालिक एस्केलेशन का उपयोग करें।
सॉफ्ट डिलीट को पूर्ण इरेज़र मानना → डेटा विशेषाधिकार प्राप्त प्रश्नों, निर्यातों, रीप्ले या रीस्टोर के लिए पठनीय बना रहता है → सॉफ्ट डिलीट का उपयोग केवल एक स्वीकृत प्रतिबंध चरण के रूप में करें और अंतिम कार्रवाई या समाप्ति को ट्रैक करें।
वर्तमान क्वेरी द्वारा शून्य लौटाए जाने के बाद Iceberg डिलीट को पूर्ण चिह्नित करना → बनाए रखे गए स्नैपशॉट अभी भी पुरानी फ़ाइलों को संदर्भित कर सकते हैं → स्नैपशॉट स्थिति रिकॉर्ड करें और स्वीकृत समाप्ति और सफाई चरण की प्रतीक्षा करें।
यह मान लेना कि प्रत्येक एग्रीगेट गुमनाम है → छोटे समूह, जॉइन कुंजियाँ और उपनाम अभी भी किसी व्यक्ति की पहचान कर सकते हैं या उसे अलग कर सकते हैं → एक स्पष्ट एनोनिमाइज़ेशन निर्णय प्राप्त करें और आवश्यकता पड़ने पर प्रभावित आउटपुट को फिर से बनाएं।
रीप्ले और रीस्टोर की अनदेखी करना → बाद का बैकफ़िल या बैकअप रिकवरी हर जगह डेटा को फिर से बना सकती है → एक न्यूनतम सप्रेशन रजिस्ट्री बनाए रखें और रीस्टोर किए गए डेटा को सर्व किए जाने से पहले डिलीशन लेज़र को फिर से लागू करें।
साक्ष्य के रूप में कच्चे पहचान मूल्यों को लॉग करना → ऑडिट ट्रेल हटाए गए डेटा की एक नई अनियंत्रित प्रति बन जाता है → अपारदर्शी संदर्भ, गणना, वर्ज़न, स्थिति परिवर्तन और प्रतिबंधित साक्ष्य संग्रहीत करें।
"प्रोसेसर को अनुरोध भेजा गया" को पूर्णता मानना → डिलीवरी यह साबित नहीं करती है कि प्रोसेसर ने कार्रवाई की → अनुबंध के अनुसार पावती, अंतिम पुष्टि, समय सीमा और एस्केलेशन को ट्रैक करें।
म्यूटेशन जॉब को स्वयं को सत्यापित करने देना → एक सफल कॉल पुराने इंडेक्स, स्नैपशॉट या मूक नो-ऑप्स (no-ops) को मिस कर सकती है → स्वतंत्र टारगेट प्रोब और एंड-टू-एंड रीप्ले और रीस्टोर परीक्षण चलाएं।

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

फॉलो-अप 1: आप एग्रीगेट टेबल को प्रभावित करने वाले डिलीशन अनुरोध को कैसे संभालेंगे?

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

फॉलो-अप 2: आप हटाए गए पंक्तियों को फिर से बनाने से Kafka रीप्ले को कैसे रोकते हैं?

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

फॉलो-अप 3: जब कोई पुराना बैकअप रीस्टोर किया जाता है तो क्या होता है?

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

फॉलो-अप 4: क्या होगा यदि कोई आवश्यक डेटा स्टोर समय सीमा के पास अनुपलब्ध हो?

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

फॉलो-अप 5: आप डिलीशन के बाद खाता पुनर्निर्माण का समर्थन कैसे करेंगे?

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

फॉलो-अप 6: क्या क्रिप्टोग्राफ़िक इरेज़र भौतिक विलोपन की जगह ले सकता है?

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

फॉलो-अप 7: आप कैसे जानते हैं कि कैटलॉग पूर्ण है?

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