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

प्रॉम्प्ट और दायरा

एक कोटा सर्विस यह उत्तर देती है कि क्या किसी संसाधन की मात्रा पर अभी दावा किया जा सकता है; यह फ़ाइलों को स्थानांतरित नहीं करती है या व्यावसायिक संचालन निष्पादित नहीं करती है। डिज़ाइन को साझा इंफ्रास्ट्रक्चर को निष्पक्ष रखते हुए आधिकारिक क्षमता (authoritative capacity), अस्थायी रिज़र्वेशन और अंतिम उपयोग को अलग करना चाहिए।

इंटरव्यूअर क्या जांच रहा है

• रेट लिमिट्स, क्षमता कोटा, रिज़र्वेशन और कमिट्स के बीच अंतर करना।
• समवर्ती अपडेट्स और इडेम्पोटेंट (idempotent) APIs के साथ ओवरसेल को रोकना।
• कॉलर के क्रैश होने और पुनः प्रयासों (retries) के बाद समाप्त हो चुके रिज़र्वेशन को पुनः प्राप्त (recover) करना।
• टेनेंट निष्पक्षता, हॉट कीज़, क्षेत्रीय निरंतरता (consistency) और डिग्रेडेशन पर विचार करना।

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

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

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

मैं limit, committed, और reserved के साथ प्रति संसाधन कुंजी एक आधिकारिक स्टेट मशीन बनाए रखूंगा, जो reserve, commit, release, और query APIs को एक्सपोज़ करेगी। Reserve एक एटॉमिक सशर्त जांच करता है और इसमें एक इडेम्पोटेंट reservation_id और समाप्ति समय (expiry) होता है। Commit एक रिज़र्वेशन को उपयोग में बदलता है; release या expiry इसे वापस कर देती है। एक इम्यूटेबल इवेंट लेज़र और सामंजस्य (reconciliation) ड्रिफ्ट को ठीक करते हैं, जबकि रूटिंग और निष्पक्षता नियम एक हॉट टेनेंट द्वारा दूसरों को भूखा रखने (starving) से रोकते हैं।

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

1. स्टेट और API सीमाओं को परिभाषित करें

प्रत्येक कोटा रिकॉर्ड में एक संसाधन कुंजी, सीमा (limit), कमिट की गई मात्रा, रिज़र्व की गई मात्रा, वर्शन और अपडेट समय होता है। reserve एक reservation_id, उपलब्ध मात्रा और समाप्ति समय लौटाता है; commit केवल अपने रिज़र्वेशन का उपभोग कर सकता है; release दोहराने योग्य है; query शेष क्षमता और नवीनता लौटाती है। कॉलर संसाधन लिखने से पहले रिज़र्व करता है, सफलता के बाद कमिट करता है, और विफलता या रद्दीकरण पर रिलीज़ करता है।

2. Concurrency के तहत ओवरसेल को रोकें

एक संसाधन-कुंजी अपडेट एक एटॉमिक लेनदेन या लीनियरिज़ेबल स्टोर ऑपरेशन होना चाहिए: केवल तभी रिज़र्व करें जब committed + reserved + amount <= limit हो। एक ही इडेम्पोटेन्सी कुंजी को दोहराने पर मूल परिणाम मिलता है; इसके मापदंडों को बदलने पर अस्वीकार कर दिया जाता है। हॉट कीज़ को टेनेंट या संसाधन द्वारा शार्ड किया जा सकता है, लेकिन डिज़ाइन में यह स्पष्ट होना चाहिए कि क्या अस्थायी अधिकता (overage) की अनुमति है और शार्ड्स का सामंजस्य कैसे होता है।

3. लीक हुए रिज़र्वेशन को पुनः प्राप्त करें

कॉलर रिज़र्व करने के बाद क्रैश हो सकते हैं, इसलिए समाप्ति समय संग्रहीत करें और स्कैनर या विलंबित कतार (delayed queue) के माध्यम से पुनः प्राप्त करें। स्टेट शर्तों के साथ रिकवरी और कमिट के बीच रेस को संभालें: एक कमिटेड रिज़र्वेशन को रिलीज़ नहीं किया जा सकता है, और एक रिलीज़ किए गए रिज़र्वेशन को कमिट नहीं किया जा सकता है। रिक्लेम लैग को ट्रैक करें ताकि विलंबित क्लीनअप को उपलब्ध क्षमता समझने की भूल न हो।

4. साझा पूल्स और निष्पक्षता को संभालें

एक साझा पूल में ग्लोबल, टेनेंट और प्रोजेक्ट बाधाएं (constraints) हो सकती हैं। उन्हें एक निश्चित क्रम में और एक लेनदेन के भीतर जांचें। टेनेंट कोटा, प्राथमिकता या भारित निष्पक्षता (weighted fairness) द्वारा बर्स्ट आवंटित करें ताकि एक टेनेंट पूरे पूल का उपभोग न कर सके। ब्लाइंड री-ट्राई को कम करने के लिए शेष क्षमता, री-ट्राई समय, या कतार की स्थिति लौटाएं।

5. विफलताओं, रीजन्स और सामंजस्य को डिज़ाइन करें

यदि अथॉरिटी अनुपलब्ध है, तो किसी अज्ञात स्थिति से बिल योग्य क्षमता खर्च करने के बजाय रूढ़िवादी रूप से उच्च जोखिम वाले रिज़र्वेशन को अस्वीकार करें; कम जोखिम वाले रीड्स टाइमस्टैम्प युक्त अनुमान लौटा सकते हैं। किसी टेनेंट को होम रीजन में पिन करें, या एक स्पष्ट स्थानीय अधिकता सीमा परिभाषित करें और एसिंक्रोनस रूप से सामंजस्य करें। प्रत्येक reserve, commit, और release को एक इम्यूटेबल लेज़र में लिखें, वास्तविक संसाधन उपयोग के साथ इसकी तुलना करें, और इडेम्पोटेंट क्षतिपूर्ति जॉब्स के साथ ड्रिफ्ट की मरम्मत करें।

एक सशक्त नमूना उत्तर

मैं संसाधन, टेनेंट पदानुक्रम, रिज़र्वेशन जीवनकाल और निरंतरता की आवश्यकता को स्पष्ट करूंगा। सर्विस प्रति संसाधन कुंजी सीमा, कमिटेड, रिज़र्व्ड और वर्शन संग्रहीत करती है और reservation_id-आधारित reserve, commit, release, और query संचालन एक्सपोज़ करती है। Reserve एटॉमिक रूप से योग की जांच करता है; पुनः प्रयास समान परिणाम लौटाते हैं। कॉलर सफल लेखन के बाद कमिट करते हैं, विफलता पर रिलीज़ करते हैं, और एक रिक्लेमर समाप्ति को संभालता है। साझा पूल्स एक साथ ग्लोबल और टेनेंट सीमाओं की जांच करते हैं और निश्चित रूटिंग, प्राथमिकता या भारित निष्पक्षता का उपयोग करते हैं। अथॉरिटी विफलता पर, उच्च जोखिम वाले राइट्स विफल (fail closed) हो जाते हैं। क्रॉस-रीजन प्लेसमेंट एक टेनेंट होम रीजन या एक स्पष्ट सीमित अधिकता का उपयोग करता है। एक इम्यूटेबल लेज़र और आवधिक सामंजस्य ट्रैक किए गए कोटा को वास्तविक उपयोग के साथ संरेखित रखते हैं।

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

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

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

कॉलर कमिट करने से पहले टाइम आउट हो जाता है। री-ट्राई करें या फिर से रिज़र्व करें?

पहले उसी reservation_id के साथ क्वेरी करें या कमिट का पुनः प्रयास करें। यह पुष्टि करने के बाद ही एक नया रिज़र्वेशन बनाएं कि पुराना वाला रिलीज़ हो गया था या समाप्त हो गया था।

क्या होगा यदि कई प्रोडक्ट्स एक टेनेंट कोटा साझा करते हैं?

टेनेंट को साझा पैरेंट और प्रोडक्ट्स को चाइल्ड बाधाओं के रूप में मानें, दोनों को एक ही लेनदेन में जांचें। रिपोर्ट करें कि कौन सी परत समाप्त हो गई है ताकि क्लाइंट्स कतारबद्ध या डिग्रेड हो सकें।

क्या रीजन्स समवर्ती रूप से रिज़र्व कर सकते हैं?

गैर-ओवरसेल योग्य बिलिंग क्षमता के लिए, एक अथॉरिटी या मजबूत समन्वय का उपयोग करें। यदि सीमित अधिकता स्वीकार्य है, तो प्रत्येक रीजन को एक उधार सीमा दें और ऋण का स्पष्ट रूप से सामंजस्य करें।

आप कोटा ड्रिफ्ट का पता कैसे लगाते हैं?

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