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

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

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

प्रश्न

एक ऐसा गेटवे डिज़ाइन करें जो यह तय करे कि कौन से अनुरोध सेवा क्षमता का उपभोग कर सकते हैं और कौन से अनुरोध तब तेजी से विफल (fail fast) होते हैं जब सेवा या कोई डिपेंडेंसी संतृप्ति (saturation) के करीब हो, जबकि महत्वपूर्ण कार्य के लिए पूर्वानुमेय लेटेंसी (predictable latency) बनी रहे।

समस्या और दायरा

गेटवे कई APIs के सामने कार्य करता है। एक मिनट में ट्रैफ़िक 20 गुना बढ़ सकता है, जबकि डेटाबेस, सर्च और थर्ड-पार्टी डिपेंडेंसीज़ की क्षमता भिन्न होती है। अनुरोध वर्गीकरण (request classification), एडमिशन, क्यूज़, लोड शेडिंग, डिग्रेडेड रिस्पॉन्स और रिकवरी डिज़ाइन करें। व्यावसायिक ऑथराइजेशन (business authorization), एक पूर्ण WAF, और किसी टूटी हुई डिपेंडेंसी में क्षमता जोड़ना इस दायरे से बाहर हैं।

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

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

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

  • कौन से अनुरोध महत्वपूर्ण हैं, और किन्हें विलंबित, कैश या अनुमानित (approximated) किया जा सकता है?
  • क्या आप गेटवे, किसी एक डिपेंडेंसी, किसी एक टेनेंट या प्रत्येक सीमा की सुरक्षा कर रहे हैं?
  • कार्य कितनी देर तक प्रतीक्षा कर सकता है, और क्या क्लाइंट्स को पुनः प्रयास (retry) करना चाहिए, पोल करना चाहिए, या खाली परिणाम स्वीकार करना चाहिए?
  • क्या क्षमता टेनेंट्स, रीजन्स, APIs या लागत वर्गों में निष्पक्ष होनी चाहिए?
  • कॉलर्स को कौन से स्टेटस कोड, हेडर और निर्णय मेट्रिक्स दिखाई देते हैं?

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

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

चरण-दर-चरण गहन डिज़ाइन

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

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

शेड्यूलर प्राथमिकता, टेनेंट भार (weight) और आयु के आधार पर कार्य का चयन करता है। महत्वपूर्ण कार्य को न्यूनतम कन्करेंसी आरक्षण प्राप्त होता है; कम प्राथमिकता वाले कार्य को ड्रॉप या विलंबित किया जा सकता है, जिसमें भुखमरी को रोकने के लिए एजिंग (aging) शामिल है। एक टेनेंट का बर्स्ट दूसरे टेनेंट के आरक्षण को उधार नहीं ले सकता। रीजन्स के बीच, स्थानीय त्वरित निर्णय एक नाजुक वैश्विक समन्वय डिपेंडेंसी जोड़ने के बजाय सीमित काउंटर त्रुटि (bounded counter error) स्वीकार कर सकते हैं।

प्रत्येक छोटी विंडो में, एक कंट्रोलर लक्ष्य कन्करेंसी को समायोजित करता है: जब p95 लेटेंसी, क्यू आयु, या डाउनस्ट्रीम एरर थ्रेशोल्ड पार करते हैं तो इसे कम करें; स्थिर होने पर इसे धीरे-धीरे बढ़ाएं। स्मूथ सिग्नल्स और हिस्टैरिसीस (hysteresis) थ्रेशोल्ड दोलन (oscillation) को रोकते हैं। क्लाइंट पुनः प्रयास स्वास्थ्य संकेत नहीं हैं। पुनः प्रयास प्रवर्धन (retry amplification) को ट्रैक करें और Retry-After, जिटर और पुनः प्रयास बजट के साथ रिटर्न ट्रैफ़िक को सीमित करें।

अनुरोध सिमेंटिक्स के अनुसार शेडिंग चुनें। सुझाव (recommendations), एनालिटिक्स और पूर्वावलोकन कैश किए गए या अनुमानित परिणाम लौटा सकते हैं; राइट्स (writes), भुगतान और अनुमति परिवर्तन आमतौर पर तेजी से विफल होते हैं और सुरक्षित पुनः प्रयास की मांग करते हैं। एक डिग्रेडेड रिस्पॉन्स पूर्ण होने का नाटक करने के बजाय संस्करण, टाइमस्टैम्प और नवीनता (freshness) ले जाता है। गेटवे को किसी ऐसे गैर-दोहराए जाने योग्य साइड इफेक्ट को ड्रॉप नहीं करना चाहिए जिसे वह नहीं समझता है।

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

एडमिशन दर, प्राथमिकता और टेनेंट द्वारा अस्वीकृति दर, सबसे पुरानी क्यू आयु, इन-फ़्लाइट कार्य, p95/p99 लेटेंसी, डाउनस्ट्रीम एरर, पुनः प्रयास प्रवर्धन, डिग्रेडेड फ्रेशनेस और रिकवरी स्लोप की निगरानी करें। वास्तविक कनेक्शन, थ्रेड्स, डेटाबेस कनेक्शन और क्यू जॉब्स के साथ संसाधन बजट का मिलान करें। ट्रैफ़िक स्पाइक्स, धीमी डिपेंडेंसीज़, खराब पॉलिसी कॉन्फ़िगरेशन, कंट्रोलर लॉस, रीजनल पार्टिशन और रीप्ले स्टॉर्म्स इंजेक्ट करें।

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

"गेटवे पर मैं विश्वसनीय क्रिटिकैलिटी, लागत, पुनः प्रयास योग्यता और डिपेंडेंसी लेबल्स संलग्न करूँगा। प्रत्येक API और डिपेंडेंसी में बाउंडेड कन्करेंसी, बाउंडेड क्यूज़ और आरक्षित क्षमता होती है; शेड्यूलर प्राथमिकता, टेनेंट भार और एजिंग का उपयोग करता है। एक कंट्रोलर हिस्टैरिसीस के साथ p95 लेटेंसी, क्यू आयु और डाउनस्ट्रीम एरर्स से लक्ष्य कन्करेंसी को समायोजित करता है। ओवरलोड के तहत यह पहले कम मूल्य वाले या पुनः प्रयास योग्य कार्य को अस्वीकार करता है और महत्वपूर्ण राइट्स के लिए क्षमता सुरक्षित रखता है; पूर्वावलोकन नवीनता (freshness) के साथ कैश डेटा लौटा सकते हैं।

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

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

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

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

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

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

फॉलो-अप 2: आप कम प्राथमिकता वाले टेनेंट्स को महत्वपूर्ण टेनेंट्स को बाहर करने से कैसे रोकते हैं?

महत्वपूर्ण टेनेंट्स के लिए एक पूल या न्यूनतम कोटा आरक्षित करें, फिर भार के अनुसार साझा क्षमता शेड्यूल करें। प्रत्येक टेनेंट को एक अधिकतम बजट दें ताकि बर्स्ट अनिश्चित काल के लिए आरक्षण उधार न ले सकें।

फॉलो-अप 3: सब कुछ कतारबद्ध (queue) क्यों नहीं करते?

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

फॉलो-अप 4: कौन से सिग्नल्स कंट्रोलर को संचालित करते हैं?

कम से कम p95/p99 लेटेंसी, इन-फ़्लाइट कार्य, सबसे पुरानी क्यू आयु, डिपेंडेंसी एरर दर, और संसाधन उपयोग। उन्हें स्मूथ करें, हिस्टैरिसीस जोड़ें, और क्लाइंट-पुनः प्रयास ट्रैफ़िक को स्वस्थ मांग से अलग करें।

फॉलो-अप 5: क्या कोई महत्वपूर्ण राइट (write) डिग्रेड हो सकता है?

केवल तभी जब व्यावसायिक सिमेंटिक्स टिकाऊ एनक्यू (enqueue) के बाद एसिंक्रोनस पूर्णता की अनुमति देते हैं। भुगतान, अनुमतियाँ और इन्वेंट्री गलत सफलता नहीं लौटा सकते; वे सुरक्षित रूप से विफल होते हैं और आइडेम्पोटेंसी के साथ पुनः प्रयास करते हैं।

फॉलो-अप 6: आप कैसे सत्यापित करते हैं कि रिकवरी फिर से ओवरलोड नहीं होगी?

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

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

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

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

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

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

टूल देखें