प्रॉम्प्ट और दायरा
यह API बाउंड्री पर प्रोटोकॉल डिज़ाइन का परीक्षण करता है। संदर्भित दस्तावेज़ 23 मई, 2026 को प्रकाशित एक सक्रिय Internet-Draft है, RFC नहीं; इसका उपयोग करने से पहले इस स्थिति का उल्लेख करें। यदि कोई डिप्लॉयमेंट प्रस्ताव के केवल एक हिस्से को अपनाता है, तब भी डिज़ाइन सुरक्षित रहना चाहिए।
इंटरव्यूअर क्या मूल्यांकन कर रहा है
- पॉलिसी मेटाडेटा और वर्तमान में उपलब्ध कोटा के बीच एक सटीक अंतर।
- स्ट्रक्चर्ड-फ़ील्ड पार्सिंग, एकाधिक विंडोज़, कोटा इकाइयाँ, और पार्टीशन कीज़।
- 429, Retry-After, गेटवे, CDN, और पुराने कैश्ड रिस्पॉन्स के साथ इंटरैक्शन।
- सीमाओं को उजागर करने से प्राइवेसी और डिनायल-ऑफ-सर्विस (DoS) जोखिम।
- क्लाइंट बैकऑफ़ जो संकेतों (hints) को गैर-बाध्यकारी मानता है और छूटे हुए या विकृत फ़ील्ड्स को सहन करता है।
अनुशंसित उत्तर संरचना
पहले कोटा आयामों और स्वामित्व को परिभाषित करें। एक रिस्पॉन्स दिखाएं जिसमें एक पॉलिसी और वर्तमान सीमा शामिल हो, फिर समझाएं कि क्लाइंट कार्य को कैसे शेड्यूल करता है। कैश और मध्यस्थ नियम, सुरक्षा बाधाएं, ऑब्जर्वेबिलिटी, और फीचर फ्लैग के साथ एक रोलआउट योजना जोड़ें ताकि ड्राफ्ट क्लाइंट्स को तोड़े बिना बदल सके।
गहन विश्लेषण: क्षमता का वादा किए बिना हेडर्स को उपयोगी बनाएं
पॉलिसी को वर्तमान स्थिति से अलग करें
RateLimit-Policy एक नामित कोटा का वर्णन करता है, जैसे कि "tenant";q=1000;w=60। RateLimit उपलब्ध कोटा और प्रभावी विंडो की रिपोर्ट करता है, उदाहरण के लिए "tenant";r=420;t=23। एक पॉलिसी में कई आइटम और परिवर्तनशील विंडो हो सकती हैं। सर्वर ही मुख्य प्राधिकारी (authority) बना रहता है: ये मान केवल संकेत (hints) हैं, कोई लीज या सेवा-स्तर की गारंटी नहीं।
पार्टीशन और यूनिट सिमेंटिक्स को परिभाषित करें
दस्तावेज़ में स्पष्ट करें कि एक कोटा इकाई का अर्थ एक अनुरोध, बाइट, टोकन, या भारित ऑपरेशन (weighted operation) है। एक पार्टीशन की टेनेंट्स या संसाधनों में अंतर कर सकती है, लेकिन कभी भी हेडर में ईमेल, कच्ची यूज़र आईडी, या सीक्रेट न डालें। पॉलिसी नामों को स्थिर और वर्ज़न युक्त रखें; पॉलिसी पहचानकर्ता को बदले बिना इकाइयों को बदलने से क्लाइंट पेसिंग असुरक्षित हो जाती है।
429 और Retry-After का समन्वय करें
जब सर्वर को पता हो कि अस्वीकृत अनुरोध का पुनः प्रयास कब किया जा सकता है, तब Retry-After लौटाएं। यदि दोनों फ़ील्ड मौजूद हैं, तो क्लाइंट Retry-After को प्राथमिकता देते हैं; RateLimit भविष्य के काम की गति (pacing) तय करने में मदद करता है। ड्राफ्ट के लिए किसी विशेष थ्रॉटलिंग एल्गोरिदम की आवश्यकता नहीं होती है, इसलिए क्लाइंट्स को अभी भी कैप्ड एक्सपोनेंशियल बैकऑफ़, जिटर, डेडलाइन्स और राइट्स (writes) के लिए एक आइडेम्पोटेंसी नियम की आवश्यकता होती है।
कैश और मध्यस्थों को प्रतिभागियों के रूप में मानें
कैश्ड रिस्पॉन्स पर RateLimit मान पुराने (stale) हो सकते हैं और जब रिस्पॉन्स की वर्तमान आयु (current age) सकारात्मक हो, तो उन्हें अनदेखा किया जाना चाहिए। कोटा सिमेंटिक्स से अनजान मध्यस्थ को रिस्पॉन्स को अधिक अनुमेय (permissive) नहीं दिखाना चाहिए। एक गेटवे जो अधिक सख्त सीमा लागू करता है, वह उस सख्त पॉलिसी को संप्रेषित कर सकता है, जबकि टेलीमेट्री ओरिजिन और गेटवे के निर्णयों को अलग-अलग रिकॉर्ड करती है।
उपलब्धता और गोपनीयता की रक्षा करें
एक बड़ी कोटा विंडो को उजागर न करें जो ट्रैफ़िक वॉल्यूम को प्रकट करती हो या किसी हमलावर को अनुरोधों को बढ़ाने (amplify) की अनुमति देती हो। उपलब्ध कोटा और प्रभावी विंडो के बीच के अनुपात को सीमित करें, आने वाले स्ट्रक्चर्ड फ़ील्ड्स को मान्य करें, और विकृत मानों को अनदेखा करें। संतृप्ति (saturation) के दौरान विज्ञापित मानों को कम करने की अनुमति है, लेकिन क्लाइंट्स को अस्वीकृति को तब भी संभालना होगा जब अंतिम संकेत स्वस्थ दिख रहा था।
नमूना उत्तर
“मैं प्रति टेनेंट और ऑपरेशन एक नामित पॉलिसी का वर्ज़न बनाऊंगा, इकाई को परिभाषित करूंगा, और पॉलिसी मेटाडेटा को वर्तमान शेष कोटा से अलग उत्सर्जित करूंगा। चूंकि यह ड्राफ्ट एक Internet-Draft है, इसलिए क्लाइंट दोनों फ़ील्ड्स को वैकल्पिक संकेतों के रूप में मानते हैं। Retry-After अस्वीकृत अनुरोध को नियंत्रित करता है; RateLimit भविष्य के काम की गति निर्धारित करता है। CDNs कैश्ड मानों को पुराना चिह्नित करते हैं, गेटवे कभी भी ओरिजिन सीमाओं को शिथिल नहीं दिखाते हैं, और पार्टीशन कीज़ में कोई पहचानकर्ता नहीं होते हैं। अनुबंध को धीरे-धीरे सक्षम करने से पहले SDKs रक्षात्मक रूप से स्ट्रक्चर्ड फ़ील्ड्स को पार्स करते हैं, जिटर और एक साझा कतार का उपयोग करते हैं, और विज्ञापित बनाम लागू सीमाओं के लिए मेट्रिक्स प्रदर्शित करते हैं।”
सामान्य विफलता मोड और समाधान
- ड्राफ्ट को RFC कहना → इसकी Internet-Draft स्थिति रिकॉर्ड करें और इसे एक वर्ज़न्ड अनुबंध के पीछे अलग रखें।
- शेष कोटा को अनुमति के रूप में उपयोग करना → इसे एक संकेत मानें; सर्वर संतृप्ति के तहत अभी भी अस्वीकार कर सकता है।
- पार्टीशन कीज़ में यूज़र पहचानकर्ता लौटाना → अपारदर्शी (opaque), कम-कार्डिनैलिटी वाले नामों का उपयोग करें और प्राइवेसी जोखिम की समीक्षा करें।
- कैश्ड हेडर्स पर भरोसा करना → पुराने मानों को अनदेखा करें और ओरिजिन को सीमा लागू करने दें।
- प्रत्येक 429 को तुरंत पुनः प्रयास करना →
Retry-Afterका सम्मान करें, जिटर जोड़ें, और विधि-विशिष्ट आइडेम्पोटेंसी लागू करें।
स्कोरिंग रूब्रिक और सेल्फ़-चेक
पॉलिसी/स्थिति पृथक्करण, इकाइयों और विभाजनों, 429 इंटरैक्शन, कैश व्यवहार, प्राइवेसी, क्लाइंट पेसिंग, रोलआउट सुरक्षा और मेट्रिक्स का स्कोर करें। एक मजबूत उत्तर बताता है कि प्रत्येक हेडर का क्या अर्थ है, यह क्या गारंटी नहीं दे सकता है, और फ़ील्ड्स के अनुपस्थित, पुराने या विकृत होने पर क्लाइंट कैसा व्यवहार करता है।
फॉलो-अप और विस्तार
क्या होगा यदि किसी रिस्पॉन्स में दो विंडो हों?
पेसिंग के लिए उस बाधा का चयन करें जो सबसे पहले समाप्त होगी, जबकि ऑब्जर्वेबिलिटी के लिए सभी वस्तुओं को बनाए रखें। SDK को विभिन्न इकाइयों या पार्टीशन कीज़ वाली विंडोज़ को चुपचाप संक्षिप्त (collapse) नहीं करना चाहिए।
क्या किसी सफल रिस्पॉन्स में RateLimit शामिल होना चाहिए?
यह शामिल हो सकता है, लेकिन क्लाइंट को यह नहीं मान लेना चाहिए कि प्रत्येक रिस्पॉन्स में यह शामिल है। केवल तभी उत्सर्जित करें जब उत्पाद के लिए उपयोगी हो और यह सुनिश्चित करें कि कैश पुराने मानों को वर्तमान वादों में न बदल दें।
आप बदलते ड्राफ्ट को कैसे रोल आउट करते हैं?
एक हेडर प्रोफ़ाइल या पॉलिसी वर्ज़न पर बातचीत करें, पार्सर फ़ॉलबैक को लॉग करें, SDK वर्ज़न द्वारा कैनरी डिप्लॉयमेंट करें, और नए फ़ील्ड्स के वैकल्पिक होने के दौरान 429 प्लस Retry-After व्यवहार को स्थिर रखें।
कौन से मेट्रिक्स साबित करते हैं कि अनुबंध काम करता है?
गेटवे और SDK वर्ज़न द्वारा विज्ञापित और लागू सीमाओं, पुराने हेडर निर्णयों, 429 दर, रीट्राई प्रवर्धन, कतार विलंब, अंतिम सफलता और प्राइवेसी-सुरक्षित पार्टीशन कार्डिनैलिटी को ट्रैक करें।