प्रतिनिधि इंटरव्यू विषय

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

सिस्टम डिज़ाइनकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक SaaS प्लेटफ़ॉर्म हज़ारों टेनेंट्स के लिए डेटाबेस पासवर्ड, थर्ड-पार्टी API कीज़ और साइनिंग कीज़ का प्रबंधन करता है। आप एक स्वचालित रोटेशन कंट्रोल प्लेन कैसे डिज़ाइन करेंगे जो कंज़्यूमर्स को सत्यापित करे, परिवर्तनों को धीरे-धीरे रोल आउट करे, रोलबैक का समर्थन करे, और सीक्रेट वैल्यूज़ को उजागर किए बिना लीक हुए क्रेडेंशियल्स को निरस्त (revoke) करे?

प्रॉम्प्ट और उपयुक्त संदर्भ

यह एक सुरक्षा सिस्टम-डिज़ाइन प्रश्न है। इसका मुख्य केंद्र यह है कि कैसे एक कंट्रोल प्लेन सीक्रेट वर्ज़न्स, टेनेंट पॉलिसी, कंज़्यूमर पुष्टिकरण और रोलआउट विंडो के बीच समन्वय स्थापित करता है, जबकि डेटा प्लेन केवल एक अधिकृत वर्तमान वर्ज़न को पढ़ता है। AWS डेटाबेस कटओवर व्यवधान को कम करने के लिए यूज़र्स को बारी-बारी से बदलने (alternating users) का तरीका प्रदर्शित करता है, जबकि Google Secret Manager बाइंडिंग और क्रमिक रोलआउट के लिए इम्यूटिएबल वर्ज़न्स और उपनामों (aliases) का उपयोग करता है। किसी एक क्लाउड API की नकल करने के बजाय उन पैटर्न्स को एक ऑडिट करने योग्य मल्टी-टेनेंट वर्कफ़्लो में अमूर्त (abstract) करें।

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

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

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

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

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

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

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

1. टेनेंट, सीक्रेट और पॉलिसी सीमाओं को मॉडल करें

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

2. एक लंबित वर्ज़न उत्पन्न और अलग करें

शेड्यूलर एक आइडेम्पोटेंट रोटेशन जॉब बनाता है, एक pending वर्ज़न उत्पन्न करता है, और इसके कारण, पैरेंट वर्ज़न और समाप्ति तिथि को रिकॉर्ड करता है। जनरेटर और डिस्ट्रीब्यूटर अलग-अलग होते हैं, और लॉग में कभी भी वैल्यूज़ नहीं होती हैं। थर्ड-पार्टी अपडेट्स न्यूनतम विशेषाधिकार (least privilege) और अल्पकालिक क्रेडेंशियल्स का उपयोग करते हैं। AWS की अल्टरनेटिंग-यूज़र रणनीति कटओवर से पहले बैकअप क्रेडेंशियल तैयार करने और उसे मान्य करने का उदाहरण देती है, लेकिन प्रत्येक निर्भरता (dependency) को अपने स्वयं के एडेप्टर की आवश्यकता होती है।

3. धीरे-धीरे वितरित करें और कंज़्यूमर्स को सत्यापित करें

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

4. एटॉमिक रूप से स्विच करें, ओवरलैप करें और रोल बैक करें

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

5. तत्काल निरस्त करें, पुनर्प्राप्त करें और निरीक्षण करें

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

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

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

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

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

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

क्या होगा यदि कोई कंज़्यूमर हॉट-रीलोड नहीं कर सकता है?

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

क्या होगा यदि दो रोटेशन जॉब्स एक साथ चलती हैं?

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

क्या होगा यदि कोई थर्ड-पार्टी अपडेट सफल हो जाता है लेकिन स्थानीय पर्सिस्टेंस विफल हो जाता है?

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

आप ओवरलैप विंडो कैसे चुनते हैं?

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

कंट्रोल-प्लेन विफलता के दौरान डेटा प्लेन कैसे काम करता है?

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

सार्वजनिक स्रोत

संबंधित प्रश्न

संबंधित इंटरव्यू टूल

सिस्टम डिज़ाइन उत्तर के लिए हल करें का उपयोग करें

पहले आवश्यकताओं को स्पष्ट करें, फिर स्केल, आर्किटेक्चर, कंपोनेंट चयन और ट्रेड-ऑफ की ओर बढ़ें।

टूल देखें