सिस्टम डिज़ाइन इंटरव्यू: मल्टी-रीजन ट्रैफ़िक स्टीयरिंग और फ़ेलओवर डिज़ाइन करें

प्रॉम्प्ट और उपयोग के मामले (Use Cases)

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

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

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

उत्तर देने से पहले स्पष्टीकरण

• कौन से रीजन, ट्रैफ़िक पीक और सिंगल-रीजन फ़ेलियर मॉडल लागू होते हैं?
• RTO, RPO, डेटा रेजिडेंसी और अनुपालन (compliance) संबंधी क्या बाधाएं हैं?
• क्या अनुरोध अधिकतर स्टेटलेस रीड्स हैं, या उनमें राइट्स और लंबे समय तक चलने वाले कनेक्शन्स शामिल हैं?
• क्या स्टीयरिंग DNS, Anycast, एज प्रॉक्सी, या सर्विस मेश द्वारा की जाती है?
• हेल्थ चेक्स को किन यूजर जर्नी और डिपेंडेंसीज को कवर करना चाहिए?
• क्लाइंट DNS TTL, कनेक्शन माइग्रेशन और फ़ेलबैक विंडोज़ की क्या आवश्यकताएं हैं?

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

"मैं सबसे पहले रीजनल फ़ेलियर, पीक लोड और RTO/RPO को परिभाषित करूंगा। DNS या एक एज एंट्री पॉइंट लेटेंसी-आधारित उम्मीदवारों का चयन कर सकता है, लेकिन केवल लेयर्ड हेल्थ चेक्स पास करने वाले और अतिरिक्त कैपेसिटी वाले रीजनों को ही ट्रैफ़िक प्राप्त होता है। ओवरलोड के दौरान, हम प्राथमिकता के आधार पर रेट-लिमिट और डिग्रेड करते हैं ताकि बैकअप रीजन सुरक्षित रहे। राइट्स स्पष्ट रेप्लिकेशन लैग और पुनः प्रयास (retry) सिमेंटिक्स के साथ एक डेटा-ओनरशिप सीमा का पालन करते हैं। एक डैम्प्ड कंट्रोलर धीरे-धीरे वेट (weight) शिफ्ट करता है, और हम फ़ेलबैक से पहले रिहर्सल, वार्म-अप और मेट्रिक्स को सत्यापित करते हैं।"

स्टेप-बाय-स्टेप डीप डाइव

स्टेप 1: विफलता और उद्देश्यों को परिभाषित करें। रीजन, डिपेंडेंसी, नेटवर्क और कंट्रोल-प्लेन विफलता के दायरे को स्पष्ट करें, फिर RTO, RPO, पीक और डिग्रेडेशन स्तरों को निर्धारित करें।

स्टेप 2: निर्णय लेयर्स को अलग करें। DNS या एक ग्लोबल एंट्री पॉइंट मोटे तौर पर रीजन का चयन संभालता है; एज या सर्विस लेयर्स लाइव वेट्स, कनेक्शन्स और लोकल लिमिट्स को संभालती हैं। एक ही कंट्रोल प्लेन पर विफलता की हर कार्रवाई का बोझ न डालें।

स्टेप 3: हेल्थ सिग्नल तैयार करें। कई स्थानों से प्रोब्स, क्रिटिकल यूजर जर्नी, डिपेंडेंसी स्थिति, एरर रेट और कैपेसिटी को संयोजित करें। लगातार विंडोज़, रिकवरी विंडोज़ और कोरम जैसे निर्णय फ़्लैपिंग को कम करते हैं।

स्टेप 4: कैपेसिटी सुरक्षित करें। फ़ेलओवर हेडरूम आरक्षित करें और प्रति-रीजन कॉनकरेंसी, कतार (queue) और रेट लिमिट्स सेट करें। विफलता के दौरान, इससे पहले कि क्रिटिकल ट्रैफ़िक कैस्केड का कारण बने, कम प्राथमिकता वाले काम को छोड़ (shed) दें।

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

स्टेप 6: फ़ेलओवर निष्पादित करें। कंट्रोलर कारण, वर्ज़न और अनुमोदन रिकॉर्ड करता है, विफल रीजन का वेट कम करता है, और विस्तार करने से पहले एक छोटे समूह को शिफ्ट करता है। लंबे समय तक चलने वाले कनेक्शन्स के लिए बैकऑफ़ और सेशन रिकवरी की आवश्यकता होती है।

स्टेप 7: फ़ेलबैक का रिहर्सल करें। पुनर्प्राप्त रीजन को वार्म करें, स्थिर मेट्रिक्स और डेटा चेक्स सत्यापित करें, फिर फ़ेलबैक करें। रीजनल, डिपेंडेंसी और कंट्रोल-प्लेन विफलताओं को नियमित रूप से इंजेक्ट करें और मापे गए RTO/RPO साक्ष्य को सुरक्षित रखें।

उच्च गुणवत्ता वाला मॉडल उत्तर

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

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

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

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

फॉलो-अप 1: यदि DNS TTL लंबा हो तो क्या होगा?

तेज़ वेट परिवर्तनों के लिए एज का उपयोग करें और TTL, रिकर्सिव कैश और कनेक्शन लाइफटाइम को RTO बजट में शामिल करें; तुरंत माइग्रेशन का वादा न करें।

फॉलो-अप 2: यदि हेल्थ चेकिंग ही विफल हो जाए तो क्या होगा?

स्वतंत्र कंट्रोल पाथ और कई स्थानों से प्रोब्स का उपयोग करें, फ्रेशनेस को ट्रैक करें, और चेक्स समाप्त होने पर अंतिम सुरक्षित स्थिति बनाए रखें या एक सुरक्षित मैनुअल मोड में प्रवेश करें।

फॉलो-अप 3: यदि बैकअप कैपेसिटी अपर्याप्त हो तो क्या होगा?

कैपेसिटी को आरक्षित और वार्म करें, फिर प्राथमिकता के अनुसार रेट-लिमिट, डिग्रेड या कतारबद्ध करें। लोड टेस्ट के साथ सिंगल-रीजन सीमा साबित करें।

फॉलो-अप 4: आप फ़्लैपिंग को कैसे रोकते हैं?

विभिन्न विफलता और रिकवरी थ्रेसहोल्ड, न्यूनतम ड्वेल टाइम, कूलडाउन और अनुमोदन का उपयोग करें, जिसमें प्रत्येक वेट परिवर्तन के लिए एक कारण दर्ज हो।

फॉलो-अप 5: आप क्रॉस-रीजन राइट कॉन्फ़्लिक्ट्स को कैसे संभालते हैं?

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

फॉलो-अप 6: आप कैसे साबित करेंगे कि यह काम करता है?

रीजनल, डिपेंडेंसी, नेटवर्क और कंट्रोल-प्लेन विफलताओं का अभ्यास करें और RTO, RPO, एरर्स, रिकवर की गई कैपेसिटी, रीकनेक्ट्स और डेटा चेक्स को मापें।

फॉलो-अप 7: आपको मल्टी-रीजन से कब बचना चाहिए?

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