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

सिस्टम डिज़ाइन इंटरव्यू: आप एक सुसंगत, रोलबैक-सुरक्षित फ़ीचर फ़्लैग मूल्यांकन (feature flag evaluation) कैसे बनाएंगे?

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

प्रश्न

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

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

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

साक्षात्कारकर्ता क्या जांच रहा है

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

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

  1. क्या मूल्यांकन दृढ़ता से सुसंगत (strongly consistent) होना चाहिए, या बासी डेटा (stale data) स्वीकार्य है? अधिकतम स्वीकार्य बासीपन क्या है?
  2. टेनेंट, उपयोगकर्ता, डिवाइस, क्षेत्र और संस्करण के लिए नियम प्राथमिकता (precedence) क्या है?
  3. जब कंट्रोल प्लेन अनुपलब्ध हो तो सेवाओं को कब तक चलना चाहिए, और डिफ़ॉल्ट को कौन स्वीकृत करता है?
  4. कौन से संदर्भ फ़ील्ड व्यक्तिगत डेटा हैं, और कौन से एक्सपोज़र लॉग में जा सकते हैं?
  5. क्या बहु-भाषा SDK और स्थानीय ऑफ़लाइन मूल्यांकन आवश्यक हैं, या एक रिमोट इवैल्यूएटर स्वीकार्य है?

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

कंट्रोल प्लेन नियमों को मान्य करेगा, अपरिवर्तनीय (immutable) संस्करण प्रकाशित करेगा, स्वीकृति देगा और रोलबैक करेगा। डेटा-प्लेन SDK कम विलंबता (low latency) और ऑफ़लाइन संचालन के लिए संस्करणयुक्त स्थानीय स्नैपशॉट का मूल्यांकन करेंगे। संदर्भ स्पष्ट ओवरराइड क्रम और न्यूनतम फ़ील्ड के साथ वैश्विक, लेनदेन और आमंत्रण (invocation) स्कोप को मर्ज करेगा। इंस्टेंस TTL और संस्करण एकरसता (monotonicity) जांच के साथ स्ट्रीमिंग और पोलिंग के माध्यम से अपडेट प्राप्त करेंगे। विफलताएं एक टाइप किए गए डिफ़ॉल्ट या अंतिम-ज्ञात-अच्छे (last-known-good) मान का उपयोग करेंगी और बासीपन को उजागर करेंगी; महत्वपूर्ण फ़्लैग फ़ेल-क्लोज़्ड (fail closed) हो सकते हैं। ऑडिट इवेंट में संस्करण और अनाम कुंजियां होंगी, कभी भी अपरिष्कृत (raw) विशेषताएं नहीं।

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

चरण 1: ऑब्जेक्ट और रिलीज़ स्टेट मशीन को परिभाषित करें

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

चरण 2: मूल्यांकन संदर्भ डिज़ाइन करें

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

चरण 3: स्थानीय या रिमोट मूल्यांकन चुनें

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

चरण 4: कैश और स्थिरता लक्ष्य स्थापित करें

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

चरण 5: विफलताओं और सुरक्षित डिफ़ॉल्ट को संभालें

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

चरण 6: ऑडिट और एक्सपोज़र टेलीमेट्री डिज़ाइन करें

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

चरण 7: रोलबैक और माइग्रेशन सत्यापित करें

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

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

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

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

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

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: यदि कॉन्फ़िगरेशन सेवा डाउन है तो क्या मूल्यांकन जारी रह सकता है?

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

अनुवर्ती 2: आप भाषा SDKs को सुसंगत कैसे रखते हैं?

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

अनुवर्ती 3: आप कैनरी प्रतिशत को स्थिर कैसे रखते हैं?

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

अनुवर्ती 4: हुक (hooks) का उपयोग क्यों करें?

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

अनुवर्ती 5: आप किसी फ़्लैग को सुरक्षित रूप से कैसे हटाते हैं?

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

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

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

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

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

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

टूल देखें