प्रॉम्प्ट और संदर्भ
एक सर्विस डेटाबेस, पेमेंट प्रोवाइडर और अनुशंसा (recommendation) प्रणाली को कॉल करती है। अनुशंसाओं की गति 10 ms से घटकर 1 सेकंड हो जाती है। इन-फ़्लाइट अनुरोध तब तक बढ़ते हैं जब तक कि थ्रेड्स और कनेक्शन्स समाप्त नहीं हो जाते, और जिन APIs को अनुशंसाओं की आवश्यकता नहीं होती वे भी विफल हो जाते हैं। बल्कहेड्स डिज़ाइन करें ताकि धीमी डिपेंडेंसी केवल संबंधित कार्यक्षमता को प्रभावित करे।
AWS Builders’ Library इसे लेटेंसी-ड्रिवन समवर्तीता ओवरलोड के रूप में वर्णित करती है: टाइमआउट समवर्तीता की सीमा नहीं है। प्रत्येक डिपेंडेंसी या क्लाइंट के इर्द-गिर्द संसाधनों को अलग किया जाना चाहिए, जिससे सर्विस और डाउनस्ट्रीम सिस्टम दोनों की सुरक्षा हो सके।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप Little’s Law के अंतर्ज्ञान को समझाते हैं कि उच्च सर्विस समय समान आगमन दर (arrival rate) पर इन-फ़्लाइट कार्य को बढ़ाता है।
- क्या आप डिपेंडेंसी, API, टेनेंट या रिसोर्स पूल द्वारा समवर्तीता आवंटित करते हैं ताकि एक धीमी डिपेंडेंसी वैश्विक क्षमता को समाप्त न कर सके।
- क्या आप निष्पक्षता (fairness) और उपयोगिता ट्रेड-ऑफ़ के साथ हार्ड, सॉफ्ट और डायनामिक कोटा की तुलना करते हैं।
- क्या आप तेज़ रिजेक्शन, डिग्रेडेशन, डेडलाइन्स, सर्किट व्यवहार, रिकवरी और ऑब्जर्वेबिलिटी डिज़ाइन करते हैं।
- क्या आप साबित करते हैं कि असंबंधित APIs बिना किसी असीमित कतारों या भुखमरी (starvation) के स्वस्थ रहते हैं।
पहले स्पष्ट करने योग्य प्रश्न
- कौन से APIs अनुशंसाओं को कॉल करते हैं और कौन से महत्वपूर्ण (critical) हैं? क्या कोई पाथ डिग्रेड हो सकता है?
- थ्रेड, कनेक्शन, मेमोरी और कतार की सीमाएं क्या हैं और वर्तमान समवर्तीता वितरण क्या है?
- क्या डिपेंडेंसी कैंसिलेशन, आइडम्पोटेंसी, बैचिंग या कैशिंग का समर्थन करती है? कॉलर डेडलाइन कैसे प्रचारित की जाती है?
- क्या बजट API, डिपेंडेंसी, टेनेंट या Availability Zone द्वारा अलग किया गया है? क्या क्षमता उधार (borrowing) लेने की आवश्यकता है?
- विफलता के दौरान कौन सा उपयोगकर्ता अनुभव, त्रुटि अनुबंध और रिकवरी उद्देश्य लागू होता है?
30-सेकंड का उत्तर
“मैं प्रति डिपेंडेंसी एक बाउंडेड समवर्तीता बल्कहेड और कतार बनाता हूँ, जिसमें क्रिटिकल और डिग्रेडेबल APIs के लिए अलग-अलग पूल होते हैं। अनुरोधों में एक डेडलाइन होती है; बजट से अधिक का कार्य हमेशा प्रतीक्षा करने के बजाय तेज़ी से विफल हो जाता है या कैश से डेटा प्रदान करता है। मैं उपयोगिता के लिए सॉफ्ट कोटा का उपयोग करता हूँ लेकिन बाउंडेड उधार के साथ हार्ड ग्लोबल और प्रति-क्लास सीमाएं रखता हूँ। मेट्रिक्स डिपेंडेंसी और API द्वारा इन-फ़्लाइट कार्य, रिजेक्ट्स, प्रतीक्षा, टाइमआउट, डिग्रेडेशन और रिकवरी को कवर करते हैं। धीमी-डिपेंडेंसी परीक्षण के दौरान असंबंधित APIs को स्वस्थ रहना चाहिए।”
चरण-दर-चरण समाधान
चरण 1: लेटेंसी-ड्रिवन समवर्तीता की गणना करें
प्रति डिपेंडेंसी आगमन दर, सर्विस समय, इन-फ़्लाइट अनुरोध और टाइमआउट को मापें। यदि सर्विस समय 10 ms से बढ़कर 1 s हो जाता है, तो समान आगमन दर पर इन-फ़्लाइट कार्य लगभग 100 गुना बढ़ सकता है। बल्कहेड्स का आकार तय करने से पहले सीमित संसाधनों का पता लगाएं।
चरण 2: संसाधन पूलों को विभाजित करें
प्रत्येक डिपेंडेंसी को उसका स्वयं का कनेक्शन पूल, सेमाफोर और बाउंडेड कतार दें; उसी डिपेंडेंसी के लिए क्रिटिकल और डिग्रेडेबल APIs को अलग करें। सत्यापित करें कि आइसोलेशन वास्तविक है: थ्रेड्स, कनेक्शन्स और स्थिति अलग-अलग काउंटरों के पीछे साझा नहीं रहने चाहिए।
चरण 3: हार्ड, सॉफ्ट और डायनामिक कोटा चुनें
हार्ड कोटा एक API की सुरक्षा करते हैं लेकिन लोड के उतार-चढ़ाव में क्षमता बर्बाद करते हैं। सॉफ्ट कोटा वैश्विक सीमा के तहत निष्क्रिय क्षमता उधार लेते हैं। डायनामिक कोटा लोड के अनुसार अनुकूलित होते हैं लेकिन न्यूनतम गारंटी, अधिकतम सीमा और एक सुरक्षित परिवर्तन दर की आवश्यकता होती है। निष्पक्षता महत्वपूर्ण होने पर टेनेंट विभाजन जोड़ें।
global_limit = 500
payments = hard 150
recommendations = soft 200, borrow <= 100
other_apis = reserved 50चरण 4: जानबूझकर अस्वीकार और डिग्रेड करें
यदि कोई परमिट उपलब्ध नहीं है, तो असीमित कतार में प्रवेश करने के बजाय एक स्पष्ट त्रुटि लौटाएं या कैश परिणाम दें। कॉलर डेडलाइन का सम्मान करें और रद्द किए जा सकने वाले कार्य को रद्द करें। पुनः प्रयासों (retries) के लिए एक बजट, बैकऑफ़ और आइडम्पोटेंसी की आवश्यकता होती है; महत्वपूर्ण राइट्स (writes) को चुपचाप डिग्रेड नहीं किया जाना चाहिए।
चरण 5: दोलन (oscillation) के बिना रिकवर करें
रिकवरी के बाद, परमिट धीरे-धीरे बढ़ाएं और अचानक उछाल से बचने के लिए हाफ-ओपन प्रोब्स का उपयोग करें। डिपेंडेंसी, API, टेनेंट और सेल द्वारा विभाजित रिजेक्ट्स, टाइमआउट और कतार वॉटरमार्क के लिए टाइम सीरीज़ बनाए रखें। कॉन्फ़िगरेशन को वर्शन करें और रोलबैक क्षमता बनाए रखें।
चरण 6: आइसोलेशन सीमा सत्यापित करें
एक डिपेंडेंसी में लेटेंसी, त्रुटियां और कनेक्शन समाप्ति इंजेक्ट करें। अनुशंसा रिजेक्ट्स, भुगतान सफलता, वैश्विक थ्रेड/कनेक्शन उपयोग और टेल लेटेंसी का निरीक्षण करें। बर्स्ट्स, टेनेंट विषमता, कॉन्फ़िगरेशन परिवर्तन और सेल विफलता का परीक्षण करें; असंबंधित API SLOs और कतार सीमाएं स्वीकृति द्वार हैं।
एक मजबूत नमूना उत्तर
“मैं यह दिखाने के लिए आगमन दर, सर्विस समय और इन-फ़्लाइट कार्य का उपयोग करता हूँ कि एक धीमी अनुशंसा डिपेंडेंसी समवर्तीता को क्यों कई गुना बढ़ा देती है। प्रत्येक डिपेंडेंसी का अपना सेमाफोर, पूल और बाउंडेड कतार होती है; क्रिटिकल और डिग्रेडेबल APIs अलग होते हैं। भुगतानों को एक हार्ड रिज़र्वेशन मिलता है; अनुशंसाएं बाउंडेड उधार के साथ एक सॉफ्ट कोटा का उपयोग करती हैं। प्रत्येक कॉल एक डेडलाइन का प्रचार करती है और परमिट समाप्त होने पर तेज़ी से विफल हो जाती है या कैश लौटाती है।”
“रिकवरी हाफ-ओपन प्रोब्स और क्रमिक परमिट वृद्धि का उपयोग करती है। मेट्रिक्स में इन-फ़्लाइट कार्य, रिजेक्ट्स, प्रतीक्षा, टाइमआउट, डिग्रेडेशन हिट्स, डाउनस्ट्रीम त्रुटियां और रिकवरी समय शामिल हैं। एक ड्रिल केवल अनुशंसाओं को धीमा करती है और जाँचती है कि भुगतान और असंबंधित API टेल्स, पूल्स और थ्रेड्स सीमा के भीतर रहें।”
सामान्य गलतियाँ
- केवल टाइमआउट बढ़ाना → इन-फ़्लाइट कार्य बढ़ता है → डिपेंडेंसी-लेवल समवर्तीता सीमाएं निर्धारित करें।
- एक ही थ्रेड और कनेक्शन पूल साझा करना → एक धीमी डिपेंडेंसी पूरी सर्विस को गिरा देती है → डिपेंडेंसी और क्रिटिकैलिटी द्वारा विभाजित करें।
- असीमित कतार का उपयोग करना → मेमोरी और लेटेंसी नियंत्रण से बाहर हो जाती हैं → इसे सीमित करें और तेज़ी से रिजेक्ट करें।
- हर जगह स्थिर हार्ड कोटा → लोड विषमता से क्षमता बेकार रह जाती है → बाउंडेड सॉफ्ट उधार की अनुमति दें।
- बिना बजट के पुनः प्रयास (retry) करना → डाउनस्ट्रीम ओवरलोड बढ़ जाता है → डेडलाइन का प्रचार करें, प्रयासों को सीमित करें और आइडम्पोटेंसी की आवश्यकता रखें।
- केवल विफल डिपेंडेंसी का परीक्षण करना → आइसोलेशन अप्रमाणित रहता है → असंबंधित API SLOs को एक साथ सत्यापित करें।
अनुवर्ती प्रश्न और उत्तर
टाइमआउट समवर्तीता सीमा क्यों नहीं है?
यह केवल एक प्रतीक्षा को सीमित करता है, लेकिन प्रतीक्षा कर रहा अनुरोध अभी भी एक थ्रेड, कनेक्शन और मेमोरी पर कब्जा कर रहा होता है। उच्च डिपेंडेंसी लेटेंसी अधिक अनुरोधों को इन-फ़्लाइट रखती है, इसलिए परमिट को सीमित किया जाना चाहिए।
सॉफ्ट बॉरोइंग एक API को सब कुछ लेने से कैसे रोकती है?
एक वैश्विक सीमा, प्रति-API न्यूनतम रिज़र्वेशन, अधिकतम उधार और रिक्लेम दर का उपयोग करें। एक बार जब उधारकर्ता अपनी सीमा तक पहुंच जाता है, तो यह हमेशा बढ़ने के बजाय तेज़ी से विफल हो जाता है।
कैश लौटाना कब सुरक्षित है?
उन रीड्स के लिए जहां सीमित बासीपन (bounded staleness) स्वीकार्य है, टाइमस्टैम्प वाला कैश मान लौटाएं। भुगतान, प्राधिकरण और राइट परिणामों को चुपचाप बासी डेटा से नहीं बदला जा सकता है।
आप कैसे साबित करते हैं कि आइसोलेशन काम करता है?
एक डिपेंडेंसी में धीमापन और त्रुटियां इंजेक्ट करें, फिर असंबंधित API इन-फ़्लाइट कार्य, टेल्स, थ्रेड/कनेक्शन उपयोग और सफलता का निरीक्षण करें। सिंक्रोनस डिग्रेडेशन का अर्थ है कि एक साझा संसाधन या कतार सीमा अभी भी मौजूद है।