प्रॉम्प्ट और दायरा
यह केवल एक Redis काउंटर का नहीं, बल्कि रेट लिमिटिंग की प्रोटोकॉल सीमा का परीक्षण करता है। RFC 6585 एक अवधि में बहुत अधिक अनुरोधों के लिए 429 को परिभाषित करता है और Retry-After की अनुमति देता है; RFC 9110 सेकंड और एक HTTP दिनांक (date) को परिभाषित करता है। उन सिमेंटिक्स को ऐसे व्यवहार में बदलें जिसे क्लाइंट सुरक्षित रूप से निष्पादित कर सकें।
इंटरव्यूअर क्या मूल्यांकन कर रहा है
- लिमिट कीज़, विंडोज़, कोटा और रिस्पॉन्स फ़ील्ड्स जो यह समझाते हैं कि कौन सीमित है और रिकवरी कब संभव है।
- सुसंगत 429 बॉडी, Retry-After, रिक्वेस्ट ID और सुरक्षित कोटा विवरण।
- क्लाइंट द्वारा सेकंड या दिनांक का पार्सिंग, जिटर (jitter), डेडलाइन्स और प्रयास बजट (attempt budgets)।
- नॉन-आइडेम्पोटेंट राइट्स, एसिंक्रोनस जॉब्स और नेटवर्क टाइमआउट्स के लिए पुनः प्रयास की सीमाएँ।
- लिमिट हिट्स, रिकवरी समय, पुनः प्रयास प्रवर्धन (retry amplification), और अंतिम सफलता के मेट्रिक्स।
अनुशंसित उत्तर संरचना
लिमिट डायमेंशन्स और त्रुटि श्रेणियों को परिभाषित करें। एक 429 रिस्पॉन्स और Retry-After नियम दिखाएं। क्लाइंट प्रतीक्षा करने, छोड़ देने या एसिंक्रोनस कार्य पर स्विच करने के लिए हेडर, अनुरोध प्रकार और स्थानीय बजट का उपयोग करता है; प्रत्येक पुनः प्रयास जिटर के साथ कैप्ड एक्सपोनेंशियल बैकऑफ़ का उपयोग करता है। गेटवे, एप्लिकेशन, SDK और व्यावसायिक संचालन जिम्मेदारियों तथा फॉल्ट-इंजेक्शन परीक्षणों के साथ समाप्त करें।
गहन विश्लेषण: रिस्पॉन्स से पुनः प्रयास तक
सीमा को स्पष्टीकरण-योग्य बनाएं
टेनेंट, क्रेडेंशियल, IP, एंडपॉइंट या किसी ग्लोबल संसाधन द्वारा लिमिट्स को की (key) करें। एक स्थिर त्रुटि प्रकार, रिक्वेस्ट ID और सुरक्षित कारण लौटाएं। यदि कई लिमिटर्स ट्रिगर होते हैं, तो किसी अन्य टेनेंट के कोटा को प्रकट किए बिना सबसे लंबी ज्ञात प्रतीक्षा अवधि का उपयोग करें।
Retry-After को सही ढंग से जनरेट करें
विलंब का अर्थ है कम से कम कितने सेकंड प्रतीक्षा करनी है; एक HTTP दिनांक का अर्थ है रिकवरी का समय। मोनोटोनिक क्लॉक के साथ आंतरिक विंडोज़ की गणना करें, राउंड अप करें और मान को सीमित (cap) करें। क्लाइंट्स को अभी भी न्यूनतम प्रतीक्षा और जिटर की आवश्यकता होती है क्योंकि दिनांक क्लॉक स्क्रू या प्रॉक्सी से प्रभावित हो सकते हैं।
क्लाइंट पर पार्स और बैकऑफ़ करें
पहले Retry-After का सम्मान करें; यदि यह गायब है या अमान्य है, तो कैप्ड एक्सपोनेंशियल बैकऑफ़ का उपयोग करें। प्रत्येक लॉजिकल अनुरोध को कुल डेडलाइन और प्रयास बजट दें। एक साझा कतार या टोकन बजट के माध्यम से समवर्ती कार्य का समन्वय करें ताकि कई कार्य एक साथ सक्रिय न हों।
आइडेम्पोटेंसी सीमाओं का सम्मान करें
GET, HEAD और स्पष्ट रूप से आइडेम्पोटेंट PUT या DELETE आमतौर पर पुनः प्रयास करने योग्य होते हैं। POST के लिए एक आइडेम्पोटेंसी की और मेल खाने वाले सर्वर सिमेंटिक्स की आवश्यकता होती है। यदि निष्पादन के बाद कोई रिस्पॉन्स खो गया था, तो दूसरा साइड इफ़ेक्ट बनाने के बजाय स्थिति की क्वेरी करें या उसी की का पुनः उपयोग करें।
केवल त्रुटियों को नहीं, बल्कि रिकवरी को भी ऑब्ज़र्व करें
रिकॉर्ड लिमिट डायमेंशन, 429 काउंट, Retry-After डिस्ट्रीब्यूशन, क्लाइंट प्रतीक्षा, पुनः प्रयास प्रवर्धन, अंतिम सफलता और परित्याग (abandonment)। तत्काल पुनः अनुरोध को वैध ट्रैफ़िक वृद्धि से अलग करने के लिए SDK संस्करण और टेनेंट द्वारा विभाजित करें।
नमूना उत्तर
"मैं टेनेंट, क्रेडेंशियल और एंडपॉइंट द्वारा रेट-लिमिट करूँगा और एक स्थिर त्रुटि प्रकार, रिक्वेस्ट ID, सुरक्षित कारण और Retry-After लौटाऊँगा। सर्वर एक मोनोटोनिक-विंडो विलंब की गणना करता है, इसे राउंड अप करता है और इसे कैप करता है। SDKs पहले Retry-After को पार्स करते हैं और अन्यथा जिटर्ड एक्सपोनेंशियल बैकऑफ़ का उपयोग करते हैं; प्रत्येक लॉजिकल अनुरोध की एक डेडलाइन और प्रयास सीमा होती है। GET पुनः प्रयास योग्य है; POST को एक आइडेम्पोटेंसी की या स्थिति क्वेरी की आवश्यकता होती है। मैं 429s, प्रतीक्षा वितरण, पुनः प्रयास प्रवर्धन, अंतिम सफलता और परित्याग की निगरानी करूँगा, फिर सुचारू रिकवरी को सत्यापित करने के लिए एक सिंक्रनाइज़्ड मल्टी-क्लाइंट परीक्षण चलाऊँगा।"
सामान्य विफलता मोड और उनके समाधान
- प्रत्येक विफलता पर पुनः प्रयास करना → स्थिति, मेथड सिमेंटिक्स और त्रुटि प्रकार द्वारा वर्गीकृत करें।
- Retry-After फ़ॉर्मेट्स को अनदेखा करना → सेकंड और HTTP दिनांकों का समर्थन करें और अमान्य मानों को सुरक्षित रूप से अस्वीकार करें।
- प्रति थ्रेड तत्काल पुनः प्रयास → एक बजट, कतार और जिटर साझा करें।
- यह मान लेना कि POST आइडेम्पोटेंट है → एक आइडेम्पोटेंसी की, स्थिति क्वेरी, या स्पष्ट नो-रिट्राई परिणाम का उपयोग करें।
- केवल 429 काउंट देखना → प्रतीक्षा, प्रवर्धन, अंतिम सफलता और परित्याग को मापें।
स्कोरिंग रूब्रिक और सेल्फ़-चेक
मजबूत उत्तरों में लिमिट कीज़, 429 सिमेंटिक्स, Retry-After जेनरेशन और पार्सिंग, जिटर्ड बैकऑफ़, डेडलाइन्स, आइडेम्पोटेंसी, समवर्ती समन्वय, सुरक्षित कोटा विवरण, घटक स्वामित्व और सत्यापन मेट्रिक्स शामिल होते हैं।
पूछें: क्या क्लाइंट जानता है कि रिकवरी कब संभव है? क्या होगा यदि घड़ियाँ भिन्न हों? क्या होगा यदि हेडर गायब हो? क्या पुनः प्रयास प्रभावों की नकल कर सकते हैं? समवर्ती कार्य कैसे फैलते हैं? क्या साबित करता है कि रिकवरी में सुधार हुआ है?
फ़ॉलो-अप और विस्तार
क्या Retry-After को सेकंड या दिनांक का उपयोग करना चाहिए?
दोनों मान्य HTTP रूप हैं। सेकंड छोटी विंडोज़ के अनुकूल होते हैं और क्लॉक अंतरों से बचाते हैं; एक दिनांक एक ज्ञात रिकवरी बिंदु को व्यक्त कर सकता है। सर्वर आउटपुट को सुसंगत रखें जबकि SDK पार्सिंग को दोनों के साथ संगत बनाएं और समाप्त हो चुके मानों को संभालें।
यदि गेटवे और एप्लिकेशन दोनों सीमित करते हैं, तो कौन सी प्रतीक्षा लौटाई जाती है?
क्लाइंट-दृश्यमान प्रतीक्षा में सभी ज्ञात सीमाओं को कवर किया जाना चाहिए, सामान्यतः सबसे लंबी, एक रिक्वेस्ट ID के साथ। आंतरिक टेलीमेट्री प्रत्येक लेयर को रिकॉर्ड करती है ताकि गेटवे अस्वीकृति को गलती से एप्लिकेशन के लिए ज़िम्मेदार न ठहराया जाए।
क्या कोई क्लाइंट Retry-After के बिना पुनः प्रयास कर सकता है?
केवल तभी जब मेथड और त्रुटि सिमेंटिक्स इसकी अनुमति देते हैं, एक डेडलाइन शेष है, और स्थानीय बैकऑफ़ बजट पर्याप्त है। कैप्ड जिटर्ड बैकऑफ़ का उपयोग करें; गैर-पुनः प्रयास योग्य राइट्स के लिए एक क्वेरी-योग्य स्थिति या स्पष्ट विफलता लौटाएं।
आप पुनः प्रयास के तूफ़ान (retry storm) का परीक्षण कैसे करते हैं?
429 को ट्रिगर करने के लिए कई क्लाइंट्स को सिंक्रनाइज़ करें, फिर अमान्य हेडर, क्लॉक स्क्रू, कनेक्शन टाइमआउट और रिकवरी जिटर इंजेक्ट करें। आगमन वक्र, प्रवर्धन, रिकवरी समय और अंतिम सफलता का निरीक्षण करें।