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

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

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

इंटरव्यूअर क्या जांच रहा है

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

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

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

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

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

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

1. वर्जन्स और लॉक स्थिति का मॉडल बनाएं

ऑब्जेक्ट की (key) संरक्षित इकाई नहीं है; बल्कि objectVersionId है। कंटेंट डाइजेस्ट, राइट टाइम, retainUntil, मोड, लीगल होल्ड, टेनेंट और पॉलिसी वर्जन को स्टोर करें। एक साधारण डिलीट सुरक्षित वर्जन को भौतिक रूप से डिलीट करने के बजाय एक डिलीट मार्कर बनाता है; स्थायी डिलीट के लिए वर्जन का नाम निर्दिष्ट करना और लॉक चेक पास करना आवश्यक है।

2. राइट्स और डिफॉल्ट रिटेंशन डिज़ाइन करें

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

json

{
  "objectVersionId": "v_91c2",
  "retention": {"mode": "COMPLIANCE", "retainUntil": "2027-01-01T00:00:00Z"},
  "legalHold": "OFF",
  "policyVersion": 18
}

3. डिलीट और ओवरराइट गेट्स लागू करें

डिलीट, ओवरराइट, रिटेंशन को छोटा करना और लीगल होल्ड को हटाना एक ही ऑथराइजेशन सर्विस का उपयोग करते हैं। यह नवीनतम वर्जन को पढ़ता है और समय, मोड, प्रिंसिपल परमिशन और होल्ड स्थिति की सशर्त जांच करता है। गवर्नेंस मोड के लिए एक स्पष्ट बायपास परमिशन और रिक्वेस्ट मार्कर की आवश्यकता होती है; कंप्लायंस मोड समाप्ति से पहले सभी डिलीट्स को अस्वीकार करता है, जिसमें एडमिनिस्ट्रेटर भी शामिल हैं। रिजेक्शन पर एक स्थिर एरर और ऑडिट ID मिलता है।

4. लीगल होल्ड्स और अप्रूवल डिज़ाइन करें

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

5. रेप्लिकेशन, रिकवरी और क्लॉक्स को संभालें

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

6. ऑडिट और प्रूफ बनाएं

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

एक मजबूत उत्तर का उदाहरण

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

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

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

फॉलो-अप्स और प्रतिक्रियाएं

एक साधारण DELETE किसी वर्जन को डिलीट किए बिना कैसे सफल हो सकता है?

वर्जन्ड ऑब्जेक्ट्स के साथ, एक साधारण DELETE एक नया डिलीट मार्कर बना सकता है जो वर्तमान वर्जन को छुपा देता है जबकि सुरक्षित वर्जन बना रहता है। स्थायी डिलीट के लिए वर्जन ID निर्दिष्ट करना और लॉक गेट को पास करना आवश्यक है।

कंप्लायंस मोड को एक मजबूत अकाउंट बाउंड्री की आवश्यकता क्यों होती है?

इसका अर्थ यह है कि रूट अकाउंट या स्टोरेज एडमिनिस्ट्रेटर सहित कोई भी प्रिंसिपल रिटेंशन तिथि से पहले डिलीट नहीं कर सकता है। डिलीशन को साधारण IAM सुपरयूजर ग्रांट्स से अलग किया जाना चाहिए ताकि कोई प्रिविलेज्ड रोल कंप्लायंस को अमान्य न कर सके।

आप कैसे साबित करेंगे कि अस्वीकृत डिलीट ऑडिट से गायब नहीं हुआ?

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

क्या रेप्लिकेशन में देरी होने पर सोर्स को डिलीट किया जा सकता है?

नहीं। जब तक टारगेट कंटेंट डाइजेस्ट, वर्जन ID और रिटेंशन मेटाडेटा की पुष्टि नहीं करता, तब तक सोर्स लॉक बना रहता है; अन्यथा रेप्लिकेशन विफलता एक ऐसी स्थिति पैदा करती है जिसमें कोई भी कंप्लायंट कॉपी नहीं होती।