प्रॉम्प्ट और संदर्भ
यह प्रोडक्ट के निर्णय (product judgment) से जुड़ा प्रश्न है। एक डेवलपर API को शेयर्ड रिसोर्सेस की सुरक्षा करनी चाहिए, बिना अस्पष्ट 429 प्रतिक्रियाओं (responses) के कारण वैध इंटीग्रेशन को विफल किए। यह तय करें कि क्या सीमित करना है, किस पहचान (identity) पर सीमा लागू होती है, टियर्स में क्या अंतर है, क्लाइंट्स सीमाओं को पहले से कैसे समझ सकते हैं, और यह कैसे साबित किया जाए कि यह पॉलिसी उपयोगी कार्य को रोके बिना विश्वसनीयता में सुधार करती है।
मान लें कि free, professional और enterprise टियर्स हैं; रिक्वेस्ट की लागत रिक्वेस्ट की संख्या, कॉनकरेंसी, इनपुट साइज और डाउनस्ट्रीम कंप्यूट के आधार पर बदलती है; एक बर्स्ट द्वारा शेयर्ड डिपेंडेंसी समाप्त नहीं होनी चाहिए; और पॉलिसी को रोल आउट और रोल बैक किया जा सकता है। उदाहरण मान जैसे कि 60 RPM, प्रति माह 10,000 कॉल्स, या 80% चेतावनी केवल प्लेसहोल्डर हैं जिन्हें वास्तविक डेटा से बदला जाना चाहिए, न कि उद्योग मानक।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर तकनीकी बाधाओं से जुड़ी प्रोडक्ट रणनीति का परीक्षण करना चाहता है:
- रेट, यूसेज कोटा, कॉनकरेंसी और लागत बजट को अलग-अलग वादों (promises) के रूप में परिभाषित करना;
- केवल प्लान की कीमत के बजाय डेवलपर के किए जाने वाले काम (job to be done) से शुरुआत करना;
- ऑर्गनाइज़ेशन, प्रोजेक्ट, API key, यूज़र या IP द्वारा सीमित करने के निष्पक्षता और दुरुपयोग (abuse) के ट्रेड-ऑफ को समझाना;
- पूर्वानुमेय (predictable) एरर, हेडर्स, डैशबोर्ड, अलर्ट और अधिक क्षमता का अनुरोध करने का मार्ग प्रदान करना;
- गार्डरेल के रूप में सफलता दर, रीट्राई एम्प्लीफिकेशन, रिसोर्स लागत, रिटेंशन और सपोर्ट के बोझ को मापना;
- कैनरी (canary), अपवादों (exceptions), अपीलों, रोलबैक और पॉलिसी-परिवर्तन संचार की योजना बनाना।
एक कमजोर उत्तर "free के लिए कम सीमाएं और enterprise के लिए उच्च सीमाएं" सूचीबद्ध करता है। एक मजबूत उत्तर यह बताता है कि प्रत्येक सीमा किस चीज़ की सुरक्षा करती है, डेवलपर्स क्या अनुभव करते हैं, और साइड इफेक्ट्स को कैसे सत्यापित किया जाएगा।
पूछने के लिए स्पष्टीकरण प्रश्न
वे बाधाएं पूछें जो पॉलिसी को बदलती हैं:
- किस रिसोर्स की सुरक्षा की जा रही है? गेटवे CPU, डेटाबेस कनेक्शन्स, मॉडल टोकन्स, थर्ड-पार्टी बिल, या किसी एक टेनेंट के लिए निष्पक्ष हिस्सा? प्रत्येक को एक अलग आयाम (dimension) की आवश्यकता हो सकती है।
- वर्कलोड का स्वरूप क्या है? स्थिर रिक्वेस्ट्स, छोटे बर्स्ट्स, बैच जॉब्स और लंबे समय तक चलने वाले कनेक्शन्स प्रति-मिनट की एक ही संख्या को साझा नहीं कर सकते।
- क्या सीमा हार्ड है या सॉफ्ट बजट? एक हार्ड सीमा सुरक्षा की रक्षा करती है; एक सॉफ्ट बजट कतारबद्ध (queue) कर सकता है, सेवा को डिग्रेड कर सकता है, या अतिरिक्त शुल्क ले सकता है, लेकिन स्पष्ट फीडबैक देना आवश्यक है।
- क्या बिलिंग और थ्रॉटलिंग को एक ही इकाई में मापा जाता है? टोकन, कॉल्स और कॉनकरेंट कनेक्शन्स के लिए अलग-अलग काउंटर्स की आवश्यकता हो सकती है; एक मिश्रित मीट्रिक का पूर्वानुमान लगाना कठिन होता है।
- सफलता क्या है? कम डिपेंडेंसी ओवरलोड, पहली बार में सफल कॉल्स की अधिक संख्या, बेहतर ग्रॉस मार्जिन, या उच्च-मूल्य वाले डेवलपर रिटेंशन में वृद्धि? प्राथमिकताओं का क्रम पॉलिसी को बदल देता है।
30-सेकंड का उत्तर ढांचा (Framework)
इस प्रकार शुरुआत करें:
"मैं चार वादों को अलग करता हूँ: शॉर्ट-विंडो रेट लिमिट्स तात्कालिक क्षमता की रक्षा करती हैं, एक बिलिंग-साइकिल कोटा बजट को नियंत्रित करता है, एक कॉनकरेंसी कैप उपयोग में आने वाले निष्पादन स्लॉट (execution slots) की रक्षा करता है, और एक लागत बजट अप्रत्याशित बिल को रोकता है। मैं ऑर्गनाइज़ेशन या प्रोजेक्ट को मुख्य पहचान के रूप में उपयोग करूँगा और रिक्वेस्ट और रिसोर्स आयामों को एंडपॉइंट लागत के साथ जोड़ूँगा। टियर्स केवल RPM बढ़ाने के बजाय बजट, बर्स्ट क्षमता, कॉनकरेंसी और सपोर्ट रिस्पॉन्स जोड़ेंगे। डॉक्यूमेंटेशन, डैशबोर्ड और रिस्पॉन्स हेडर्स शेष क्षमता, रीसेट समय और Retry-After दिखाएंगे। मैं पहले शैडो-मोड में पॉलिसी का मूल्यांकन करूँगा, इसे टेनेंट्स के एक छोटे समूह पर कैनरी टेस्ट करूँगा, और विस्तार या रोलबैक करने से पहले सफलता दर, रीट्राई एम्प्लीफिकेशन, लागत, अपग्रेड और रिटेंशन पर नज़र रखूँगा।"
यह तकनीकी या व्यावसायिक फॉलो-अप से पहले इकाइयों, डेवलपर अनुभव और मापन चक्र को स्पष्ट करता है।
चरण-दर-चरण विस्तृत विश्लेषण (Step-by-step deep dive)
सीमाओं को एक प्रोडक्ट अनुबंध (contract) में बदलें। एक रेट लिमिट यह देखती है कि एक छोटी विंडो में कितनी रिक्वेस्ट्स आ सकती हैं। एक यूसेज कोटा यह देखता है कि बिलिंग अवधि में कितना रिसोर्स उपयोग हो सकता है। एक कॉनकरेंसी कैप यह देखती है कि एक समय में कितने निष्पादन स्लॉट ऑक्यूपाइड हो सकते हैं। इन्हें अलग रखने से ग्राहक यह समझ पाता है कि 429 एरर का मतलब बर्स्ट है, समाप्त हो चुका आवधिक बजट है, या पूर्ण कॉनकरेंसी है। लंबे समय तक चलने वाले जॉब्स के लिए अधिकतम रनटाइम या कतार बजट (queue budget) की भी आवश्यकता हो सकती है।
इकाइयों को प्लान के नामों से नहीं, बल्कि वर्कलोड से प्राप्त करें। सस्ते रीड्स के लिए रिक्वेस्ट काउंट का उपयोग किया जा सकता है। महंगे ऑपरेशन्स के लिए इनपुट बाइट्स, आउटपुट टोकन्स, कंप्यूट सेकंड्स या डेटाबेस स्कैन यूनिट्स की आवश्यकता हो सकती है। पहले महत्वपूर्ण ग्राहक वर्कफ़्लो को मैप करें, फिर एंडपॉइंट-विशिष्ट इकाइयों का चयन करें। ऐसे एकल RPM का वादा न करें जो प्रत्येक एंडपॉइंट की लागत का प्रतिनिधित्व करता हो।
पहचान और निष्पक्षता चुनें। पेड-API पहचान के रूप में IP की तुलना में ऑर्गनाइज़ेशन या प्रोजेक्ट आमतौर पर बेहतर होता है: NAT कई ग्राहकों को एक साथ जोड़ देता है, जबकि कीज़ को रोटेट करने से केवल-की वाली सीमा को बायपास किया जा सकता है। प्रोजेक्ट कॉनकरेंसी के साथ ऑर्गनाइज़ेशन बजट का उपयोग करें, और IP का उपयोग दुरुपयोग रोकने के गार्डरेल के रूप में करें। Enterprise अपवाद ऑडिट योग्य होने चाहिए; सेल्स का कोई वादा प्लेटफ़ॉर्म पॉलिसी को बायपास नहीं करना चाहिए।
टियर अंतर डिज़ाइन करें। Free टियर को एक छोटा एंड-टू-एंड ट्रायल पूरा करने में सक्षम होना चाहिए। Professional टियर अवधि बजट, बर्स्ट क्षमता और कॉनकरेंसी जोड़ सकता है। Enterprise आरक्षित क्षमता (reserved capacity), अनुपालन नियंत्रण या समर्पित सपोर्ट जोड़ सकता है। प्रत्येक टियर में सीमा से अधिक होने पर व्यवहार का स्पष्ट उल्लेख होना चाहिए: रिजेक्ट करना, कतारबद्ध करना, डिग्रेड करना या उपयोग के अनुसार शुल्क लेना। पूर्वानुमेयता में सुधार किए बिना केवल संख्या बढ़ाने से आमतौर पर सपोर्ट का भार बढ़ता है।
क्लाइंट के व्यवहार को पूर्वानुमेय बनाएं। डॉक्यूमेंटेशन, डैशबोर्ड और रिस्पॉन्स हेडर्स शेष क्षमता, रीसेट समय और रिक्वेस्ट ID दिखाते हैं। 429 पर, क्लाइंट्स Retry-After का सम्मान कर सकते हैं; रीट्राई कैप के साथ एक्सपोनेंशियल बैकऑफ़ रीट्राई स्टॉर्म से बचाता है। गैर-पुनर्प्रयास योग्य (non-retryable) व्यावसायिक त्रुटियों के लिए रीट्राई को प्रोत्साहित न करें। केवल "Too Many Requests" के बजाय स्थिर एरर कोड और अगला कदम बताएं।
लॉन्च और गार्डरेल मीट्रिक्स परिभाषित करें। प्राथमिक मापों में पहली बार में सफल कॉल दर, वैध-अनुरोध 429 दर, अवधि बजट के 80% तक पहुंचने वाले ग्राहकों का हिस्सा, यूनिट-रिक्वेस्ट मार्जिन, सपोर्ट संपर्क, अपग्रेड रूपांतरण और 30-दिवसीय रिटेंशन शामिल हो सकते हैं। गार्डरेल्स में रीट्राई एम्प्लीफिकेशन, डाउनस्ट्रीम p99, दुरुपयोग की घटनाएं और क्रॉस-टेनेंट विवाद शामिल हैं। प्रत्येक माप को टियर, एंडपॉइंट और वर्कलोड स्वरूप के अनुसार विभाजित (segment) करें ताकि औसत डेटा समस्याओं को छिपा न सके।
कैनरी, अपवाद और रोलबैक। पहले आंतरिक प्रोजेक्ट्स और कुछ ग्राहकों के लिए बिना रिस्पॉन्स बदले शैडो मोड में नई पॉलिसी की गणना करें। इसे लागू करने से पहले पुरानी पॉलिसी से तुलना करें। माइग्रेशन विंडो, बजट अलर्ट और अस्थायी क्षमता प्रक्रिया प्रदान करें। यदि वैध-कॉल सफलता या रीट्राई एम्प्लीफिकेशन किसी सीमा को पार करता है, तो डेटाबेस पंक्ति को मैन्युअल रूप से संपादित करने के बजाय पॉलिसी वर्ज़न को रोल बैक करें।
स्पष्ट मान्यताओं के साथ परीक्षण करें। मान लीजिए कि एक professional प्रोजेक्ट प्रति मिनट 40 स्थिर रिक्वेस्ट्स भेजता है और बर्स्ट में यह 120 तक जाता है। 60-RPM की सीमा स्थिर पथ को संभालती है लेकिन बर्स्ट के दौरान बार-बार 429 उत्पन्न करती है। एक नमूना पॉलिसी 120 की बर्स्ट क्षमता के साथ 60 RPM की अनुमति दे सकती है और मासिक बजट की अलग से गणना कर सकती है; यह केवल उदाहरण के लिए है। लोड टेस्ट में बर्स्ट्स, कॉनकरेंसी, ऑर्गनाइज़ेशन बजट साझा करने वाले कई प्रोजेक्ट्स, क्लॉक बाउंड्रीज़, रीट्राई करने वाले क्लाइंट्स और अपग्रेड के बाद पॉलिसी प्रसार (propagation) शामिल होना चाहिए।
उच्च-गुणवत्ता वाला नमूना उत्तर
"मैं संरक्षित रिसोर्स को डेवलपर के वादे से अलग रखूँगा। रेट लिमिट्स शॉर्ट-विंडो क्षमता की रक्षा करती हैं, एक आवधिक कोटा बजट को नियंत्रित करता है, और एक कॉनकरेंसी कैप ऑक्यूपाइड निष्पादन स्लॉट की रक्षा करता है; महंगे एंडपॉइंट्स इनपुट-साइज़ या कंप्यूट इकाइयां जोड़ते हैं। मैं मुख्य रूप से ऑर्गनाइज़ेशन और द्वितीयक रूप से प्रोजेक्ट द्वारा मापूँगा, IP का उपयोग केवल दुरुपयोग रोकने वाले गार्डरेल के रूप में करूँगा ताकि NAT वैध ग्राहकों को एक साथ न मिला दे। Free टियर को एक छोटा एंड-टू-एंड ट्रायल पूरा करना होगा, professional टियर आवधिक बजट, बर्स्ट और कॉनकरेंसी जोड़ता है, और enterprise आरक्षित क्षमता, अनुपालन नियंत्रण और एक ऑडिट योग्य अस्थायी वृद्धि जोड़ता है। प्रत्येक टियर यह बताता है कि सीमा से अधिक होने पर कार्य रिजेक्ट किया जाता है, कतारबद्ध किया जाता है, डिग्रेड किया जाता है या बिल किया जाता है।
क्लाइंट्स डॉक्यूमेंटेशन, डैशबोर्ड और हेडर्स में शेष क्षमता, रीसेट समय और रिक्वेस्ट ID देखते हैं। एक 429 रिस्पॉन्स Retry-After का पालन करता है, और SDK डुप्लिकेट-रिक्वेस्ट एम्प्लीफिकेशन से बचने के लिए कैप्ड एक्सपोनेंशियल बैकऑफ़ का उपयोग करता है। मैं नई पॉलिसी का शैडो-मूल्यांकन करूँगा, फिर इसे कुछ प्रोजेक्ट्स पर कैनरी टेस्ट करूँगा। प्राथमिक उपाय पहली सफल कॉल्स, वैध-कॉल 429 दर, यूनिट-रिक्वेस्ट लागत और अपग्रेड रूपांतरण हैं; गार्डरेल्स रीट्राई एम्प्लीफिकेशन, डाउनस्ट्रीम p99, सपोर्ट संपर्क और 30-दिवसीय रिटेंशन हैं। यदि वैध-कॉल विफलता सीमा पार करती है, तो मैं एक ग्राहक के लिए बिना ऑडिट वाला अपवाद बनाने के बजाय पॉलिसी वर्ज़न को रोल बैक करूँगा और माइग्रेशन अवधि बढ़ाऊँगा।"
मुख्य बिंदु प्रोडक्ट इकाइयों, पूर्वानुमेयता, तकनीकी व्यवहार और प्रयोग संबंधी निर्णयों के बीच का संबंध है। प्रत्येक संख्या को एक वास्तविक बेसलाइन से बदलें; उदाहरण कोटा डिफ़ॉल्ट नहीं हैं।
सामान्य गलतियाँ
- केवल यह कहना कि "free टियर कम, enterprise टियर उच्च।" यह संरक्षित रिसोर्स और सीमा से अधिक होने पर व्यवहार को छोड़ देता है। प्रत्येक सीमा को एक रिसोर्स, ग्राहक के काम और फीडबैक पाथ से जोड़ें।
- RPM को कुल लागत मानना। बड़े अनुरोध और लंबे जॉब्स अधिक डाउनस्ट्रीम क्षमता की खपत करते हैं। रिसोर्स या कॉनकरेंसी आयाम जोड़ें।
- IP को एकमात्र ग्राहक पहचान के रूप में उपयोग करना। NAT, प्रॉक्सी और की-रोटेशन निष्पक्षता और ऑडिटेबिलिटी को तोड़ते हैं। प्राइमरी की के रूप में ऑर्गनाइज़ेशन या प्रोजेक्ट का और गार्डरेल के रूप में IP का उपयोग करें।
- क्लाइंट्स को बिना सोचे-समझे रीट्राई करने देना। तत्काल रीट्राई से कंजेशन बढ़ता है।
Retry-Afterका सम्मान करें, एक्सपोनेंशियल बैकऑफ़ का उपयोग करें, और प्रयासों को सीमित करें। - केवल रेवेन्यू या 429 दर पर नज़र रखना। उच्च रेवेन्यू कम सफलता दर के साथ भी हो सकता है, जबकि कम 429 का मतलब अत्यधिक रिसोर्स रिजर्वेशन हो सकता है। अनुभव, लागत और विश्वसनीयता को एक साथ ट्रैक करें।
- पॉलिसी को सेल्स अपवाद से बदलना। एक गैर-दस्तावेजीकृत बैकडोर को रद्द करना कठिन होता है और यह अनुचित है। समयबद्ध, ऑडिट योग्य और प्रतिवर्ती (reversible) क्षमता प्रक्रिया का उपयोग करें।
फॉलो-अप प्रश्न और उत्तर
एक ग्राहक को बर्स्ट के दौरान 429 मिलते हैं, जबकि बहुत सारा मासिक कोटा शेष है। आप क्या करेंगे?
समझाएं कि एक आवधिक कोटा और तात्कालिक दर अलग-अलग वादे हैं। एंडपॉइंट लागत और ग्राहक वर्कफ़्लो का निरीक्षण करें, फिर एक उचित बर्स्ट छूट या एक अस्थायी बर्स्ट अनुरोध मार्ग जोड़ें। हेडर्स, दस्तावेज़ों और डैशबोर्ड में रीसेट और प्रतीक्षा व्यवहार को स्पष्ट करें। बिना साक्ष्य के हर ग्राहक का RPM न बढ़ाएं।
एक बड़ा ग्राहक रेट लिमिट्स को बायपास करने के लिए कहता है। क्या आप सहमत हैं?
वर्कलोड, डिपेंडेंसी लागत और विश्वसनीयता लक्ष्यों के बारे में पूछें। सिस्टम-व्यापी सुरक्षा गार्डरेल्स को बनाए रखते हुए आरक्षित क्षमता, एक समर्पित कतार या समयबद्ध वृद्धि की पेशकश करें। अनुमोदन, मूल्य, समाप्ति और रोलबैक को रिकॉर्ड करें। एक असीमित वादा अन्य ग्राहकों और डाउनस्ट्रीम सेवाओं पर जोखिम स्थानांतरित करता है।
429 दर गिरती है लेकिन रिटेंशन भी गिरता है। आप कैसे तय करेंगे कि पॉलिसी विफल रही?
एंडपॉइंट, टियर, वर्कलोड और माइग्रेशन चरण के अनुसार डेटा को विभाजित करें। जांचें कि क्या व्यापक सीमा ने लागत या लेटेंसी को छिपा दिया है, फिर पहली सफल कॉल्स, सपोर्ट संपर्क, बजट अलर्ट और चर्न इंटरव्यू को संयोजित करें। यदि केवल महत्वपूर्ण वर्कफ़्लो प्रभावित होते हैं, तो सभी गार्डरेल्स को हटाने से पहले इकाइयों, डॉक्यूमेंटेशन या बर्स्ट पॉलिसी को ठीक करें।
ग्राहक कई प्रोजेक्ट्स में एक बजट साझा करते हैं। आप एक प्रोजेक्ट को पूरे ऑर्गनाइज़ेशन का कोटा समाप्त करने से कैसे रोकते हैं?
दो स्तरों का उपयोग करें: एक ऑर्गनाइज़ेशन बजट और साथ ही प्रोजेक्ट कॉनकरेंसी या रिजर्वेशन्स। महंगे या जोखिम भरे एंडपॉइंट्स के लिए प्रोजेक्ट रिजर्वेशन की आवश्यकता हो सकती है। डैशबोर्ड में दोनों शेष मान दिखाएं और पहचानें कि कोई एरर प्रोजेक्ट-स्तरीय है या ऑर्गनाइज़ेशन-स्तरीय, ताकि व्यवस्थापक (admin) बजट या प्राथमिकता को समायोजित कर सके।