प्रॉम्प्ट और संदर्भ
ट्रैफ़िक स्पाइक के बाद एक API 429 Too Many Requests लौटाती है। इस स्टेटस कोड की जिम्मेदारी की सीमा, Retry-After को कैसे पढ़ें, किन अनुरोधों का पुनः प्रयास किया जा सकता है, और क्लाइंट को ओवरलोड को कैस्केडिंग विफलता में बदलने से कैसे रोका जाए, इसकी व्याख्या करें।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- 429 को सर्वर की स्थायी विफलता के बजाय एक रेट-लिमिट सिग्नल के रूप में समझना।
- Retry-After के दोनों प्रारूपों और हेडर के अनुपस्थित होने की स्थिति को सही ढंग से संभालना।
- पुनः प्रयास का निर्णय लेते समय आइडेम्पोटेंसी, समय-सीमा (deadlines) और व्यावसायिक दुष्प्रभावों (business side effects) को जोड़ना।
- एक्सपोनेंशियल बैकऑफ़, जिटर, बजट और रेट नियंत्रण के साथ सेवा की सुरक्षा करना।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या सीमा प्रति उपयोगकर्ता, टोकन, टेनेंट, IP या साझा संसाधन पर आधारित है?
- क्या प्रतिक्रिया में Retry-After शामिल है, और क्या क्लाइंट अपनी घड़ी पर भरोसा कर सकता है?
- क्या विधि और व्यावसायिक संचालन आइडेम्पोटेंट हैं, या क्या कोई आइडेम्पोटेंसी कुंजी मौजूद है?
- क्या समग्र डेडलाइन, पुनः प्रयास की अधिकतम सीमा और पुनः प्रयास बजट मौजूद हैं?
- क्या सेवा कोटा, शेष क्षमता या कोई अनुरोध ID प्रदर्शित करती है?
30-सेकंड उत्तर ढांचा
मैं 429 को रेट-लिमिट फीडबैक के रूप में मानता हूँ और Retry-After को पढ़ता हूँ, जो सेकंड या HTTP दिनांक हो सकता है। मैं एक सुरक्षित क्लाइंट बैकऑफ़ सीमा के भीतर सर्वर की सलाह का सम्मान करता हूँ और जिटर जोड़ता हूँ। मैं केवल आइडेम्पोटेंट संचालन या आइडेम्पोटेंसी कुंजी द्वारा सुरक्षित संचालन का ही डेडलाइन, प्रयास और बजट सीमाओं के साथ स्वचालित रूप से पुनः प्रयास करता हूँ। Retry-After के बिना, मैं जिटर वाले एक्सपोनेंशियल बैकऑफ़ का उपयोग करता हूँ; बार-बार 429 आने पर रुक जाता हूँ और कॉलर को नियंत्रण लौटा देता हूँ।
चरण-दर-चरण गहन विश्लेषण
चरण 1: 429 सिमेंटिक्स की पुष्टि करें
RFC 6585 किसी निश्चित अवधि में अत्यधिक अनुरोधों के लिए 429 को परिभाषित करता है और Retry-After की अनुमति देता है। यह क्लाइंट को दर कम करने के लिए कहता है; इसे 500 की तरह नहीं माना जाना चाहिए और तुरंत पुनः प्रयास नहीं किया जाना चाहिए।
चरण 2: Retry-After को पार्स करें
Retry-After गैर-ऋणात्मक पूर्णांक सेकंड या एक HTTP दिनांक हो सकता है। दिनांक के लिए, विलंब का अनुमान लगाने के लिए प्रतिक्रिया Date या किसी विश्वसनीय घड़ी का उपयोग करें, और ऋणात्मक, अत्यधिक बड़े या विकृत मानों को सीमित करें।
Retry-After: 8
Retry-After: Wed, 02 Aug 2026 02:00:00 GMTचरण 3: तय करें कि पुनः अनुरोध सुरक्षित है या नहीं
GET और HEAD जैसी सुरक्षित विधियाँ आमतौर पर पुनः प्रयास योग्य होती हैं। राइट (write) ऑपरेशनों के लिए आइडेम्पोटेंट सिमेंटिक्स, एक आइडेम्पोटेंसी कुंजी या सर्वर-साइड डिडप्लीकेशन की आवश्यकता होती है। यहाँ तक कि एक ही विधि के दुष्प्रभाव भी हो सकते हैं जैसे शुल्क लेना, मेल भेजना या कोई कार्य बनाना।
चरण 4: विलंब और बैकऑफ़ की गणना करें
पहले Retry-After का सम्मान करें, फिर क्लाइंट एक्सपोनेंशियल-बैकऑफ़ सीमा और यादृच्छिक (random) जिटर लागू करें। जिटर कई क्लाइंट्स को एक ही क्षण में जागने से रोकता है। प्रतीक्षा को अनुरोध की डेडलाइन के भीतर फिट होना चाहिए, न कि उसे हमेशा के लिए बढ़ाते रहना चाहिए।
चरण 5: पुनः प्रयास प्रवर्धन (retry amplification) को सीमित करें
प्रति-अनुरोध प्रयास, एक वैश्विक पुनः प्रयास बजट और एक कॉनक्रेन्सी सीमा निर्धारित करें। लगातार 429 लौटाने वाले संसाधन के लिए दर कम करें; आवश्यकता पड़ने पर स्थानीय कतार (queue) या सर्किट ब्रेकर का उपयोग करें ताकि पुनः प्रयास सामान्य ट्रैफ़िक क्षमता का उपभोग न करें।
चरण 6: क्लाइंट और सर्वर की जिम्मेदारियों को अलग करें
सर्वर एक स्पष्ट सीमा सिग्नल और अवलोकनीय फ़ील्ड प्रदान करता है। क्लाइंट सिग्नल का सम्मान करता है, बैकऑफ़ करता है और रुक जाता है। रिकवरी के बाद, सभी प्रतीक्षारत अनुरोधों को एक साथ छोड़ने के बजाय ट्रैफ़िक को धीरे-धीरे बढ़ाएं।
चरण 7: परिणाम रिकॉर्ड करें और सुधार करें
429 दर, Retry-After वितरण, अंतिम सफलता दर, पुनः प्रयास गणना और डेडलाइन परित्याग को ट्रैक करें। 429 को एकल-अनुरोध विफलता मानने के बजाय कोटा, क्लाइंट बजट और अलर्ट को ट्यून करने के लिए डेटा का उपयोग करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं पहले सीमा के आयाम और प्रतिक्रिया हेडर की पुष्टि करूँगा। Retry-After: 8 के साथ, क्लाइंट कम से कम आठ सेकंड प्रतीक्षा करता है; HTTP दिनांक के साथ, यह एक विश्वसनीय घड़ी और अधिकतम सीमा का उपयोग करके विलंब की गणना करता है। आइडेम्पोटेंसी कुंजी के साथ ऑर्डर लुकअप स्वचालित रूप से पुनः प्रयास कर सकता है, जबकि बिना डिडप्लीकेशन के शुल्क निर्माण की पुष्टि व्यावसायिक स्तर द्वारा की जानी चाहिए। मैं रैंडम जिटर के साथ एक्सपोनेंशियल बैकऑफ़, प्रति-अनुरोध तीन-प्रयास सीमा, एक वैश्विक पुनः प्रयास बजट और एक समग्र डेडलाइन का उपयोग करता हूँ। लगातार 429 आने पर कॉनक्रेन्सी कम हो जाती है और कतार रुक जाती है ताकि पुनः प्रयास ओवरलोड को न बढ़ाएं। मेट्रिक्स कोटा और अलर्ट ट्यूनिंग के लिए 429 दर, प्रतीक्षा समय और अंतिम सफलता दर को कवर करते हैं।
सामान्य गलतियाँ
- 429 को 500 की तरह मानना और टाइट लूप में तुरंत पुनः प्रयास करना।
- केवल पूर्णांक Retry-After का समर्थन करना और HTTP-दिनांक प्रारूप की अनदेखी करना।
- आइडेम्पोटेंट रीड्स और साइड-इफेक्ट वाले राइट्स के बीच अंतर करने में विफल होना।
- डेडलाइन, बजट या कॉनक्रेन्सी सीमाओं को छोड़ना जिससे पुनः प्रयास बिना किसी सीमा के बढ़ते रहें।
- प्रत्येक क्लाइंट को समान निश्चित विलंब देना और एक सिंक्रनाइज़्ड पुनः प्रयास स्पाइक उत्पन्न करना।
फॉलो-अप और उत्तर
फॉलो-अप 1: Retry-After के बिना कितनी देर प्रतीक्षा करनी चाहिए?
अधिकतम विलंब, प्रयास और कुल-डेडलाइन सीमाओं के साथ जिटर वाले एक्सपोनेंशियल बैकऑफ़ का उपयोग करें। एक स्थायी स्थिरांक चुनने के बजाय इसे 429 दर और कोटा से ट्यून करें।
फॉलो-अप 2: क्या होगा यदि HTTP दिनांक अतीत में है?
सर्वर विलंब को शून्य मानें लेकिन फिर भी स्थानीय बैकऑफ़ और जिटर लागू करें, और घड़ी या सर्वर-जेनरेशन समस्या को रिकॉर्ड करें। दिनांक अमान्य होने के कारण उच्च-कॉनक्रेन्सी पुनः प्रयास शुरू न करें।
फॉलो-अप 3: क्या POST का पुनः प्रयास किया जा सकता है?
केवल तभी जब API आइडेम्पोटेंसी को परिभाषित करता है, एक आइडेम्पोटेंसी कुंजी प्रदान करता है, या व्यावसायिक परत डिडप्लीकेट कर सकती है। अन्यथा स्पष्ट पुनः सबमिशन निर्णय के लिए कॉलर को वापस लौटें।
फॉलो-अप 4: क्या होगा यदि कई इंस्टेंस एक ही कोटा साझा करते हैं?
प्रक्रियाओं में या टेनेंट दायरे में पुनः प्रयास बजट और रेट नियंत्रण का समन्वय करें, कॉनक्रेन्सी को कम करने के लिए साझा सिग्नलों का उपयोग करें। प्रति-इंस्टेंस बैकऑफ़ कुल अतिरिक्त उपभोग (aggregate overage) को नहीं रोक सकता है।
फॉलो-अप 5: रिकवरी के दौरान आप ओवरलोड के एक और स्पाइक से कैसे बचते हैं?
कतार को धीरे-धीरे आगे बढ़ाएं, जिटर और कॉनक्रेन्सी सीमा बनाए रखें, और 429 तथा लेटेंसी का अवलोकन करने के बाद ही दर बढ़ाएं। सभी प्रतीक्षारत अनुरोधों को एक साथ रिलीज़ न करें।
फॉलो-अप 6: कौन से मेट्रिक्स साबित करते हैं कि रणनीति काम करती है?
टेनेंट या संसाधन द्वारा खंडित 429 दर, पुनः प्रयास प्रवर्धन, सफलता दर, P95 लेटेंसी, अंतिम परित्याग और रिकवरी समय की तुलना करें।