प्रॉम्प्ट और दायरा
आप एक ग्लोबल SaaS के मालिक हैं जहां एक क्लस्टर में डेटाबेस, कतार (queue) या डिप्लॉयमेंट की विफलता हर टेनेंट को प्रभावित कर सकती है। एक सेल-आधारित आर्किटेक्चर डिज़ाइन करें: प्रत्येक सेल एक निश्चित टेनेंट सेट को सेवा देने वाली सिस्टम की स्वतंत्र रूप से संचालित होने वाली पूर्ण प्रतिलिपि है, और एक एंट्री लेयर स्थिर मैपिंग द्वारा अनुरोधों को लक्षित सेल पर रूट करती है।
टेनेंट पार्टिशनिंग, रूटिंग डायरेक्टरी, सेल के अंदर कंप्यूट और डेटा सीमाएं, क्रॉस-सेल रिपोर्टिंग, रिलीज़, माइग्रेशन, क्षमता और डिज़ास्टर रिकवरी को कवर करें। AWS सेल को स्वतंत्र प्रतिकृतियों (replicas) के रूप में वर्णित करता है और उपयोगकर्ता-से-सेल मैपिंग को अत्यधिक उपलब्ध स्टोरेज में संग्रहीत करता है; इसका बल्कहेड मार्गदर्शन एक एंडपॉइंट के पीछे एक पार्टिशन कुंजी द्वारा रूटिंग का वर्णन करता है।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप विफलता का दायरा, टेनेंट कंसिस्टेंसी और स्वीकार्य गिरावट (degradation) को पहले परिभाषित करते हैं।
- क्या कोई सेल केवल डुप्लिकेट स्टेटलेस सेवाओं के बजाय एक वास्तविक विफलता डोमेन है।
- क्या आप रूटिंग, कंट्रोल-प्लेन, साझा-निर्भरता और क्रॉस-सेल क्वेरी जोखिमों की पहचान करते हैं।
- क्या नए सेल, रीबैलेंसिंग और टेनेंट माइग्रेशन में रिवर्सिबल (प्रतिवर्ती) कदम हैं।
- क्या सेल-स्तरीय क्षमता, त्रुटि और निर्भरता मेट्रिक्स ब्लास्ट-रेडियस के दावे को साबित करते हैं।
सिस्टम-डिज़ाइन इंटरव्यू संदर्भ सेल-आधारित आर्किटेक्चर को बहुत बड़े सिस्टम के लिए एक आइसोलेशन पैटर्न मानते हैं। एक मजबूत उत्तर बताता है कि विश्वसनीयता का लाभ डुप्लिकेट इंफ्रास्ट्रक्चर और संचालन को कब सही ठहराता है; सेल माइक्रोसर्विस का पर्यायवाची नहीं है।
उत्तर देने से पहले स्पष्टीकरण प्रश्न
- क्या लक्षित विफलता दायरा एक टेनेंट, एक सेल, एक उपलब्धता क्षेत्र (Availability Zone), या एक क्षेत्र (region) है?
- क्या टेनेंट डेटा, ग्लोबल सर्च या क्रॉस-टेनेंट एग्रीगेट्स साझा कर सकते हैं?
- किन ऑपरेशनों के लिए लीनियरिज़ेबिलिटी (linearizability) की आवश्यकता है, और कौन सी रिपोर्ट विलंबित या अंततः सुसंगत (eventually consistent) हो सकती हैं?
- क्या माइग्रेशन थोड़े समय के लिए केवल-पढ़ने योग्य (read-only) हो सकता है? क्या कोई डेटा-रेजीडेंसी बाधाएं हैं?
- उपलब्धता लक्ष्य, टेनेंट संख्या, वृद्धि, सेल क्षमता और रिलीज़ आवृत्ति क्या हैं?
30-सेकंड उत्तर फ्रेमवर्क
मैं एक स्थिर टेनेंट कुंजी को एक निश्चित सेल में मैप करूँगा। प्रत्येक सेल में कंप्यूट, कतारें, कैश और प्राथमिक डेटा स्टोरेज होता है; ग्लोबल कंट्रोल प्लेन केवल संस्करणों, क्षमता और मैपिंग का प्रबंधन करता है। एक एंट्री राउटर एक अत्यधिक उपलब्ध डायरेक्टरी को पढ़ता है और केवल विफल सेल को हटाता है। क्रॉस-सेल रिपोर्ट एसिंक्रोनस एग्रीगेशन का उपयोग करती हैं ताकि क्वेरीज़ एक साझा डेटाबेस को फिर से न बनाएं। सेल निर्माण, माइग्रेशन और रिलीज़ छोटे, अवलोकनीय, प्रतिवर्ती चरणों का उपयोग करते हैं, जिसमें सेल-स्तरीय SLOs विफलता सीमा को साबित करते हैं।
चरण-दर-चरण विस्तृत उत्तर
चरण 1: सेल सीमाओं और विफलता मान्यताओं को परिभाषित करें
सेल को एक पूर्ण प्रतिलिपि के रूप में परिभाषित करें जिसे स्वतंत्र रूप से तैनात और पुनर्प्राप्त किया जा सकता है: API, वर्कर्स, कैश, डेटाबेस, ऑब्जेक्ट-स्टोरेज प्रीफिक्स और मॉनिटरिंग। साझा पहचान (identity), बिलिंग, या कॉन्फ़िगरेशन सेवाओं को एक स्पष्ट विफलता बजट की आवश्यकता होती है। यदि एक साझा कंट्रोल प्लेन अनुपलब्ध होने पर प्रत्येक सेल को ब्लॉक करता है, तो डेटा प्लेन पूरी तरह से अलग नहीं है।
चरण 2: पार्टिशन कुंजी और रूटिंग डायरेक्टरी चुनें
एक स्थिर पार्टिशन कुंजी के रूप में tenant_id का उपयोग करें। डायरेक्टरी टेनेंट-टू-सेल मैपिंग, संस्करण, माइग्रेशन स्थिति और क्षमता संग्रहीत करती है। राउटर पहले एक स्थानीय कैश पढ़ता है और एक अत्यधिक उपलब्ध डायरेक्टरी से रीफ्रेश करता है; संस्करण संख्याएं और लीज (leases) माइग्रेशन के दौरान पुराने मार्गों को दो सेल में लिखने से रोकते हैं। क्लाइंट एक ही होस्टनेम देखते हैं जबकि राउटर पुनः प्रयास (retry) सीमाओं का प्रबंधन करता है।
चरण 3: इन-सेल डेटा प्लेन का निर्माण करें
प्रत्येक सेल का अपना प्राथमिक डेटाबेस और संदेश कतार होती है; टेनेंट डेटा को सेल के बीच समकालिक रूप से (synchronously) नहीं लिखा जाता है। प्रतिकृतियां, कैश और ऑब्जेक्ट स्टोरेज सेल पहचान रखते हैं, और बैकअप उस मेटाडेटा को बनाए रखते हैं। ग्लोबल कॉन्फ़िगरेशन एक ग्लोबल डेटाबेस पर हॉट ट्रैफ़िक भेजने के बजाय केवल-पढ़ने योग्य स्नैपशॉट या संस्करणित रोलआउट का उपयोग करता है।
चरण 4: क्रॉस-सेल प्रश्नों को संभालें
प्रत्येक सेल एक चेंज स्ट्रीम (change stream) उत्सर्जित करता है ताकि ग्लोबल एनालिटिक्स लेयर द्वारा उपभोग की जाने वाली एग्रीगेट टेबल बनाई जा सकें। रिपोर्टों में रीयल-टाइम पूर्णता का दावा करने के बजाय डेटा समय और छूटे हुए सेल मार्कर शामिल होते हैं। दृढ़ता से सुसंगत (strongly consistent) क्रॉस-टेनेंट संचालन को संकीर्ण किया जाना चाहिए, एसिंक्रोनस बनाया जाना चाहिए, या स्पष्ट रूप से एक बड़े साझा विफलता डोमेन को स्वीकार करना चाहिए; अनुरोध पथ पर टू-फेज कमिट (two-phase commit) से बचें।
चरण 5: विफलता और डिग्रेडेशन पथ डिज़ाइन करें
हेल्थ चेक इन-सेल निर्भरता, रूट पहुंच योग्यता और व्यावसायिक शुद्धता को कवर करते हैं। जब कोई सेल विफल हो जाता है, तो डायरेक्टरी इसे ड्रेनिंग (draining) के रूप में चिह्नित करती है और नए अनुरोधों को रोक देती है; उत्पाद की अनुमति होने पर रीड कैश या एसिंक्रोनस काम में गिरावट (degradation) आ सकती है। जब तक प्रतिकृति, आइडम्पोटेंसी (idempotency), और प्राधिकरण सीमाओं को सिद्ध नहीं किया जाता, तब तक टेनेंट्स को किसी भी मनमाने सेल में न ले जाएं, अन्यथा विफलता पुनर्प्राप्ति (failover) डुप्लिकेट राइट्स उत्पन्न कर सकती है।
चरण 6: सेल जोड़ें और क्षमता को पुनर्संतुलित (rebalance) करें
इंफ्रास्ट्रक्चर टेम्पलेट से एक खाली सेल बनाएं, सिंथेटिक ट्रैफ़िक और शैडो रीड्स चलाएं, फिर एक छोटे टेनेंट सेट को अनुमति दें। क्षमता संकेतों में CPU, डेटाबेस कनेक्शन, कतार विलंब, स्टोरेज वृद्धि और प्रति टेनेंट लागत शामिल हैं। रीबैलेंसिंग एक मैपिंग संस्करण को फ्रीज करता है, डेटा कॉपी और सत्यापित करता है, एक संक्षिप्त राइट हैंडऑफ़ करता है, और पुराने और नए सेल पर नजर रखता है; विफलता पर, पुराने डेटा को हटाने के बजाय मैपिंग को रोलबैक करें।
चरण 7: रिलीज़ और संस्करणों का संचालन करें
कंट्रोल प्लेन, सेल टेम्पलेट और व्यावसायिक संस्करण को अलग-अलग रिलीज़ करें। एक सेल में कैनरी (canary) करें, फिर सेल दर सेल विस्तार करें। एक अनुकूलता विंडो (compatibility window) बनाए रखें ताकि एक नया संस्करण उन फ़ील्ड्स को न लिख सके जिन्हें पुराना संस्करण नहीं पढ़ सकता है। संस्करण वितरण और त्रुटियों को सेल द्वारा दृश्यमान बनाएं; ग्लोबल औसत किसी एक खराब संस्करण को छिपा नहीं सकते हैं।
चरण 8: ब्लास्ट रेडियस और संचालन लागत सत्यापित करें
एक सेल में डेटाबेस, कतार, रूटिंग-डायरेक्टरी और डिप्लॉयमेंट विफलताओं को इंजेक्ट करें और पुष्टि करें कि केवल अपेक्षित टेनेंट ही प्रभावित हैं। सेल उपलब्धता, त्रुटि बजट, क्रॉस-सेल अनुरोध शेयर, माइग्रेशन रोलबैक समय, साझा-कंट्रोल-प्लेन निर्भरता और अतिरिक्त क्षमता को ट्रैक करें। यदि सेल दोषों को अलग करने के लिए बहुत कम हैं या डुप्लिकेट संचालन लागत विश्वसनीयता लाभ से अधिक है, तो एक सरल पार्टिशन या बल्कहेड डिज़ाइन चुनें।
मॉडल उत्तर
मैं tenant_id को एक निश्चित सेल में मैप करूँगा। प्रत्येक सेल स्वतंत्र रूप से API, कतारें, कैश और प्राथमिक स्टोरेज चलाता है; कंट्रोल प्लेन केवल संस्करणों, क्षमता और मैपिंग का प्रबंधन करता है। एकल-होस्टनेम राउटर एक संस्करणित, अत्यधिक उपलब्ध डायरेक्टरी को पढ़ता है, और एक विफल सेल कहीं और असत्यापित राइट्स स्वीकार करने के बजाय ड्रेन हो जाता है। क्रॉस-सेल रिपोर्टिंग चेंज स्ट्रीम के माध्यम से एसिंक्रोनस होती है। माइग्रेशन कॉपी, सत्यापन, एक संक्षिप्त हैंडऑफ़ और एक प्रतिवर्ती मैपिंग का उपयोग करता है। मैं सेल SLOs, साझा-निर्भरता शेयर, रोलबैक समय और विफलता अभ्यास (failure drills) के साथ ब्लास्ट-रेडियस दावे को साबित करूँगा; यदि आइसोलेशन लागत इसके लाभ से अधिक है, तो मैं एक सरल बल्कहेड का उपयोग करूँगा।
सामान्य गलतियाँ
- केवल स्टेटलेस सेवाओं की डुप्लिकेट बनाना → साझा डेटाबेस विफलता का एकल बिंदु बना रहता है → प्रत्येक सेल के डेटा और कतार की सीमा खींचें।
- विफलता के दौरान टेनेंट्स को बेतरतीब ढंग से स्थानांतरित करना → डुप्लिकेट राइट्स या प्राधिकरण बेमेल → पहले प्रतिकृति, आइडम्पोटेंसी और रूट संस्करणों को साबित करें।
- अनुरोध पथ पर सेल में एकत्र (aggregate) करना → एक नया ग्लोबल विफलता डोमेन → डेटा-समय मार्कर के साथ एसिंक्रोनस एकत्रीकरण का उपयोग करें।
- केवल ग्लोबल हेल्थ चेक का उपयोग करना → एक खराब सेल औसत में छिप जाती है → सेल-स्तरीय SLOs और संस्करण वितरण रिकॉर्ड करें।
- माइग्रेशन के दौरान रूट को सीधे बदलना → पुराने और नए राइट्स ओवरलैप होते हैं → मैपिंग संस्करणों, कॉपी सत्यापन और रोलबैक का उपयोग करें।
- प्रत्येक निर्भरता को अपना स्वयं का सेल देना → अनियंत्रित लागत और संचालन → पहले ब्लास्ट रेडियस और क्षमता लाभ का परिमाण तय करें।
फॉलो-अप और उत्तर
क्या होगा यदि रूटिंग डायरेक्टरी विफल हो जाए?
संस्करणित स्थानीय कैश और केवल-पढ़ने योग्य स्नैपशॉट रखें, मैपिंग परिवर्तनों को प्रतिबंधित करें, और मौजूदा टेनेंट्स को उनके मूल सेल पर जारी रखने दें। जब तक डायरेक्टरी पुनर्प्राप्त नहीं हो जाती, तब तक व्यापक रूप से रीबैलेंस न करें।
क्या होगा यदि व्यवस्थापक रिपोर्ट सेल में रीयल-टाइम होनी चाहिए?
अनुमत विलंब और गुम-डेटा सिमेंटिक्स को स्पष्ट करें। मजबूत निरंतरता के लिए ऑपरेशन को संकीर्ण करने या एक बड़े साझा विफलता डोमेन को स्वीकार करने की आवश्यकता हो सकती है; सामान्य रिपोर्टों में टाइमस्टैम्प्ड एसिंक्रोनस एग्रीगेट्स का उपयोग किया जाना चाहिए।
जब कोई सेल भर जाता है तो आप टेनेंट को कैसे माइग्रेट करते हैं?
डेटा कॉपी और सत्यापित करें, एक नया मैपिंग संस्करण प्रकाशित करें, एक संक्षिप्त राइट हैंडऑफ़ का समन्वय करें, और ट्रैफ़िक बढ़ाएं। स्थिरता साबित होने तक पुराने सेल को बनाए रखें; यदि नहीं होती है तो मैपिंग को रोलबैक करें।
क्या केवल कुछ सेल में एक संस्करण को डिप्लॉय करना सुरक्षित है?
हाँ, संगत स्कीमा, संस्करण दृश्यता, और एक स्पष्ट रोलआउट क्रम के साथ। ग्लोबल सफलता दर प्रति-सेल त्रुटि बजट की जगह नहीं ले सकती।
आप कैसे साबित करते हैं कि विफलता नहीं फैली?
एक सेल के अंदर डेटाबेस, कतार, रूटिंग और डिप्लॉयमेंट विफलताओं का अभ्यास (drill) करें। प्रभावित टेनेंट्स, क्रॉस-सेल अनुरोधों, पुनर्प्राप्ति समय और साझा निर्भरता कॉल्स को रिकॉर्ड करें।
आपको सेल-आधारित आर्किटेक्चर का उपयोग कब नहीं करना चाहिए?
जब टेनेंट पैमाना और विफलता की लागत कम हो, या मजबूत क्रॉस-टेनेंट निरंतरता प्रमुख हो, तो डुप्लिकेट संसाधन और माइग्रेशन जटिलता का कोई लाभ नहीं मिल सकता है।
सेल पहचान (identity) और बिलिंग कैसे साझा कर सकते हैं?
साझा सेवाओं को कम-दर वाले कंट्रोल प्लेन में रखें, केवल-पढ़ने योग्य परिणामों को कैश करें, और डिग्रेडेशन को परिभाषित करें। बिलिंग राइट्स को आइडम्पोटेंसी कुंजियों और मुआवज़े (compensation) की आवश्यकता होती है ताकि एक साझा-सेवा दोष हर डेटा प्लेन में न फैले।