सिस्टम डिज़ाइन इंटरव्यू: एक सुरक्षित फ़ीचर फ़्लैग सर्विस डिज़ाइन करें

प्रॉम्प्ट और उपयोग के मामले

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

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

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

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

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

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

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

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

चरण-दर-चरण समाधान

कोर डेटा मॉडल

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

कंट्रोल प्लेन और डेटा प्लेन

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

स्थिर रोलआउट और सुरक्षित रिलीज़

flagKey + stableSubjectId + salt को हैश करें और इसे बकेट 0 से 9999 में मैप करें। जैसे-जैसे एक्सपोज़र 1% से 5%, 25%, 50% और 100% तक बढ़ता है, पहले से शामिल यूज़र्स उसी वर्ज़न पर बने रहते हैं। रिलीज़ से पहले रूल्स और डिपेंडेंसीज़ को मान्य करें; रिलीज़ के दौरान एरर्स, टेल लेटेंसी और बिज़नेस मेट्रिक्स पर नज़र रखें। अलार्म बजने पर अंतिम सत्यापित वर्ज़न पर रोलबैक करें।

~~~text evaluate(flag, context, snapshot): rules = snapshot[flag].rules[context.environment] for rule in rules: if matches(rule.targeting, context): if rule.percentage is absent: return rule.value bucket = hash(flag.key + context.stableSubject + rule.salt) % 10000 if bucket < rule.percentage * 100: return rule.value return snapshot[flag].safeDefault ~~~

मुख्य ट्रेड-ऑफ़

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

आदर्श उत्तर

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

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

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

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

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

आप इंस्टेंसेस के बीच यूज़र अनुभव को कैसे सुसंगत रखते हैं?

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

जब कॉन्फ़िगरेशन सर्विस डाउन हो तो क्या होता है?

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

आप किसी खतरनाक फ़ीचर को कैसे अक्षम करते हैं?

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

आप खराब टारगेटिंग रूल्स को कैसे रोकते हैं?

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

आप एकाधिक रीजन्स को कैसे संभालते हैं?

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

आपको फ़ीचर फ़्लैग्स से कब बचना चाहिए?

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