सिस्टम डिज़ाइन इंटरव्यू: आप शोर मचाने वाले टेनेंट्स (Noisy Tenants) को कैसे अलग (Isolate) करते हैं और निष्पक्ष रूप से शेड्यूल करते हैं?

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

मुख्य बात प्रदर्शन का अलगाव (performance isolation) और निष्पक्षता है, न कि केवल एक tenantId जोड़ना। यह सेवा एसिंक्रोनस रिपोर्ट जॉब्स स्वीकार करती है जो कतारों, CPU, डेटाबेस स्कैन, ऑब्जेक्ट स्टोरेज और डाउनलोड बैंडविड्थ का उपभोग करते हैं। महीने के अंत में आने वाले अचानक ट्रैफ़िक के कारण कुछ टेनेंट "शोर मचाने वाले" (noisy) बन जाते हैं। सेवा के उद्देश्यों को परिभाषित करके शुरुआत करें, फिर बताएं कि क्या साझा किया गया है और क्या अलग रखा गया है।

मान लें कि एक टेनेंट केवल अपना डेटा पढ़ सकता है, रिपोर्ट एसिंक्रोनस रूप से पूरी हो सकती हैं, और क्रॉस-टेनेंट डेटा लीक की तुलना में अस्थायी देरी बेहतर है। एंटरप्राइज़ टेनेंट्स के अलग-अलग प्लान, क्षेत्र (regions) और डेटा प्रतिधारण नीतियां हो सकती हैं; अनुपालन (compliance), डेटा रेजीडेंसी और समर्पित क्षमता ऐसी अनिवार्य सीमाएं हैं जिन्हें स्पष्ट किया जाना चाहिए। निष्पक्षता का अर्थ हमेशा समान थ्रूपुट नहीं होता: अनुबंध और सुरक्षा प्राथमिकताओं के स्पष्ट, ऑडिट योग्य वेटेज (weights) हो सकते हैं।

यह परिदृश्य बैकएंड, प्लेटफ़ॉर्म, SRE और सिस्टम-डिज़ाइन इंटरव्यू के लिए उपयुक्त है। AWS शफ़ल शार्डिंग को एक मुख्य मल्टी-टेनेंट आइसोलेशन पैटर्न के रूप में प्रस्तुत करता है, जबकि सार्वजनिक सिस्टम-डिज़ाइन सामग्री टेनेंट आइसोलेशन, कोटा और नॉइज़ी नेबर्स (noisy neighbors) को सामान्य डिज़ाइन चिंताओं के रूप में मानती है। यह प्रश्न संपूर्ण SaaS सुविधा सेट के बजाय शेड्यूलिंग और ब्लास्ट रेडियस (blast radius) पर केंद्रित है।

इंटरव्यूअर्स क्या आंकते हैं

पहला, क्या आप हर आइसोलेशन सतह की पहचान कर सकते हैं? टेनेंट पहचान, जॉब्स, कतारें, वर्कर्स, डेटाबेस कनेक्शन, कैश, ऑब्जेक्ट स्टोरेज और इग्रेस (egress) सभी साझा हो सकते हैं; केवल इनग्रेस को अलग करने से शोर डाउनस्ट्रीम में प्रवेश कर जाता है।

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

तीसरा, क्या आप बड़े और छोटे टेनेंट्स के बीच लागत के ट्रेड-ऑफ़ का विश्लेषण कर सकते हैं? पूर्ण समर्पण (full dedication) से निष्क्रिय क्षमता और परिचालन संबंधी बोझ बढ़ता है; पूर्ण साझाकरण से संसाधनों के लिए टकराव (contention) पैदा होता है। एक मजबूत उत्तर में टियर और माइग्रेशन ट्रिगर शामिल होते हैं।

चौथा, क्या आप आइसोलेशन साबित कर सकते हैं? वैश्विक औसतों पर निर्भर रहने के बजाय टेनेंट, कतार और संसाधन लेयर के अनुसार लेटेंसी, रिजेक्शन, कतार की आयु (queue age), कोटा खपत, पुनः प्रयास (retries) और ड्रॉप्स को मापें।

स्पष्टीकरण के लिए प्रश्न

• सेवा के उद्देश्य क्या हैं? इंटरैक्टिव और एसिंक्रोनस कार्यों के लिए p95, अधिकतम प्रतीक्षा समय, सफलता दर और क्षेत्रीय उपलब्धता को परिभाषित करें।
• किन जॉब्स को प्राथमिकता दी जाती है? अनुबंध टियर, तत्काल मानवीय कार्य, निर्धारित रिपोर्ट और अन्वेषण के अलग-अलग वेटेज हो सकते हैं।
• डेटा और संसाधन सीमाएं क्या हैं? क्या कुछ टेनेंट्स को एक अलग डेटाबेस, क्षेत्र, कुंजी, ऑब्जेक्ट स्टोर या वर्कर पूल की आवश्यकता है?
• बर्स्ट और दीर्घकालिक कोटा कैसे मापे जाते हैं? सबमिशन दर, समवर्ती जॉब्स (concurrent jobs), स्कैन किए गए बाइट्स, CPU समय, स्टोरेज या इग्रेस?
• उपयोगकर्ताओं को कतार और रिजेक्शन कैसे दिखाई देता है? अनुमानित पूर्णता समय, पुनः प्रयास मार्गदर्शन, कोटा स्पष्टीकरण और व्यवस्थापक रिपोर्टिंग स्पष्ट होनी चाहिए।

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

"मैं पहले प्रति टेनेंट और प्लान के अनुसार लेटेंसी, सफलता, समवर्तीता और डेटा-आइसोलेशन उद्देश्यों को परिभाषित करता हूं, सबमिशन कोटा, चालू समवर्तीता और डाउनस्ट्रीम बजट को अलग करता हूं। गेटवे टेनेंट को प्रमाणित करता है, जॉब के आकार और एक इडेम्पोटेंसी कुंजी (idempotency key) को मान्य करता है, और एक टिकाऊ कतार में लिखता है। एक शेड्यूलर प्रति-टेनेंट टोकन बकेट और वेटेड फेयर कतारों (weighted fair queues) का उपयोग करता है; शोर मचाने वाले या विनियमित टेनेंट्स को समर्पित या शफ़ल-शार्डेड वर्कर पूल में स्थानांतरित किया जा सकता है। डेटाबेस स्कैन, कैश, ऑब्जेक्ट स्टोरेज और इग्रेस को भी मापा जाता है। ओवरलोड के दौरान, वास्तविक स्थिति और रद्दीकरण समर्थन के साथ कम प्राथमिकता वाले काम को अस्वीकार या स्थगित करें। क्रॉस-टेनेंट ऑथराइजेशन परीक्षणों, नॉइज़ इंजेक्शन, विफलता अभ्यासों और प्रति-टेनेंट p99, ब्लास्ट-रेडियस और रिकवरी दावों के साथ इसे मान्य करें।"

चरण-दर-चरण उत्तर

चरण 1: संसाधन और सेवा उद्देश्यों को परिभाषित करें

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

चरण 2: विश्वसनीय टेनेंट संदर्भ स्थापित करें

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

authenticated principal
  -> authorize tenant and report definition
  -> assign quota class and priority
  -> enqueue {tenantId, taskId, costEstimate, deadline}
  -> every worker and storage call re-checks tenant scope

चरण 3: आइसोलेशन टियर चुनें

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

चरण 4: कोटा और निष्पक्ष शेड्यूलिंग डिज़ाइन करें

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

चरण 5: डाउनस्ट्रीम संसाधनों को सुरक्षित रखें

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

चरण 6: बर्स्ट, विफलता और रिकवरी को संभालें

जॉब की स्थिति, कोटा स्नैपशॉट, एक इडेम्पोटेंसी कुंजी और रद्दीकरण को बनाए रखें (persist करें)। क्रैश हुआ वर्कर पुनः प्रयास कर सकता है, लेकिन परिणाम लेखन एक संस्करण या परिणाम कुंजी के माध्यम से इडेम्पोटेंट होना चाहिए। जब कोई निर्भरता अनुपलब्ध हो, तो केवल प्रभावित वर्गों को रोकें, कतार की आयु और अनुमानों को सुरक्षित रखें, और पूर्ण पुनः प्रयास तूफान (retry storm) से बचें। रिकवरी पर, सभी बैकलॉग को एक साथ जारी करने के बजाय p99, त्रुटियों और कोटा पर नज़र रखते हुए प्रति टेनेंट और प्राथमिकता के अनुसार प्रवेश को धीरे-धीरे बढ़ाएं।

चरण 7: स्केल, माइग्रेट और मान्य करें

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

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

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

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

अधिक उपयोग होने पर, मैं एक ईमानदार कतार या अस्थायी-ओवरलोड स्थिति लौटाता हूं और रद्दीकरण का समर्थन करता हूं; क्लाइंट हमेशा के लिए पुनः प्रयास नहीं कर सकते। वर्कर्स इडेम्पोटेंट परिणाम कुंजियों का उपयोग करते हैं, जबकि निर्भरता विफलता केवल प्रभावित कार्य को रोकती है और रिकवरी टेनेंट और प्राथमिकता के अनुसार धीरे-धीरे होती है।

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

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

• अनुरोध से आए tenantId पर भरोसा करना → एक कॉलर स्कोप को जाली बना सकता है → इसे प्रमाणीकरण से प्राप्त करें और डाउनस्ट्रीम में पुनः जांचें।
• प्रत्येक टेनेंट को एक निश्चित वर्कर देना → निष्क्रिय क्षमता बढ़ती है और विफलताएं अभी भी फैलती हैं → आवश्यकतानुसार जोखिम टियर और संयोजन शार्ड्स का उपयोग करें।
• केवल सबमिशन दर को सीमित करना → इन-फ़्लाइट कार्य अभी भी डाउनस्ट्रीम संसाधनों का उपभोग करता है → समवर्तीता, लागत और निर्भरताओं को भी सीमित करें।
• निष्पक्षता के लिए वैश्विक औसतों का उपयोग करना → छोटे टेनेंट्स की टेल लेटेंसी छिप जाती है → टेनेंट के अनुसार p95, p99, कतार और अस्वीकृति रिकॉर्ड करें।
• ओवरलोड के तहत लगातार पुनः प्रयास करना → पुनः प्रयास प्रवर्धन (retry amplification) सेवा को बंद कर देता है → स्पष्ट स्थिति, इडेम्पोटेंट पुनः प्रयास और साझा बजट लौटाएं।
• डेटाबेस बजट के बिना वर्कर्स जोड़ना → निर्भरता बाधा (bottleneck) बन जाती है → प्रत्येक संसाधन परत का शुरू से अंत तक बजट बनाएं।
• रिकवरी पर सभी बैकलॉग को एक साथ जारी करना → एक नया पीक बन जाता है → हिस्टैरिसीस और क्रमिक प्रवेश का उपयोग करें।
• इडेम्पोटेंट स्थिति के बिना माइग्रेट करना → जॉब्स डुप्लिकेट हो जाते हैं या परिणाम गायब हो जाते हैं → संस्करणों, परिणाम कुंजियों और रोलबैक का उपयोग करें।

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

फॉलो-अप 1: शफ़ल शार्डिंग साधारण शार्डिंग से किस प्रकार भिन्न है?

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

फॉलो-अप 2: क्या कोई प्रीमियम टेनेंट निष्पक्ष शेड्यूलिंग को बायपास कर सकता है?

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

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

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

फॉलो-अप 4: आप कैसे साबित करते हैं कि कोई क्रॉस-टेनेंट डेटा लीक नहीं है?

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