API दर सीमा: सीमाओं, बर्स्ट और बैकऑफ़ की पूरी गाइड

दर सीमा के बिना कोई API ठीक उस क्षण तक शानदार चलती है जब तक कोई क्लाइंट बिना किसी ठहराव वाला लूप नहीं लिख देता। उसके बाद एक ही कॉलर उस क्षमता को खा जाता है जिसे सब साझा करते हैं, हर दूसरे उपयोगकर्ता के लिए विलंब बढ़ जाता है, और विफलता किसी एक बिगड़ी स्क्रिप्ट के बजाय पूरी सेवा के ठप होने जैसी दिखती है। दर सीमा वह तंत्र है जो इस स्थिति को एक क्लाइंट के लिए छोटी, सीमित और साफ़-साफ़ चिह्नित त्रुटि में बदल देती है।

सीमाएँ ठीक रखना मुख्य रूप से स्पष्ट होने की बात है: तय करना कि आप क्या गिन रहे हैं, किस अवधि में, किस आधार पर, और सीमा पार करने वाले क्लाइंट को आप क्या बताते हैं। यह गाइड एल्गोरिदम, बचाव योग्य आँकड़े चुनने का तरीका, वे हेडर जिनसे अच्छा क्लाइंट आपकी सीमाओं में बना रहता है, और जब क्लाइंट आप खुद हों तो धीमा होने का तरीका बताती है।

दर सीमा क्यों मायने रखती है

सीमाएँ आमतौर पर किसी घटना के बाद लगाई जाती हैं, पर वे एक साथ चार अलग समस्याएँ हल करती हैं:

• क्षमता की सुरक्षा। आपकी सेवा की एक अधिकतम टिकाऊ क्षमता है। सीमा माँग को उसके नीचे रखती है — डिज़ाइन से, किस्मत से नहीं।
• न्यायसंगतता। प्रति-क्लाइंट सीमा के बिना सबसे शोर करने वाले कॉलर को सबसे अधिक संसाधन मिलते हैं। सीमा के साथ हर क्लाइंट को अनुमानित हिस्सा मिलता है।
• लागत पर नियंत्रण। अगर हर अनुरोध एक डेटाबेस क्वेरी, किसी तीसरे पक्ष की कॉल या किसी मॉडल का आह्वान करता है, तो असीमित API का मतलब असीमित बिल है।
• दुरुपयोग से बचाव। क्रेडेंशियल स्टफ़िंग, स्क्रैपिंग और एन्यूमरेशन सब मात्रा पर टिके हैं। सीमा उन्हें इतना धीमा कर देती है कि वे अव्यवहारिक हो जाएँ और इतना दिखने लायक कि उन पर अलर्ट बन सके।

एक पाँचवाँ, कम चर्चित लाभ भी है: दर्ज की गई सीमा एक अनुबंध है। क्लाइंट उसका पालन करने के लिए बनाए जा सकते हैं, जो अपनी ऊपरी हद से टकराकर उसे जानने से कहीं बेहतर है।

जानने लायक एल्गोरिदम

हर लिमिटर एक ही सवाल का जवाब देता है — क्या इस अनुरोध की अभी अनुमति है? — पर वे बर्स्ट से निपटने के तरीके में भिन्न हैं, और क्लाइंट के तौर पर आप असल में वही अंतर महसूस करते हैं।

टोकन बकेट

एक बकेट की कल्पना करें जिसमें तय संख्या में टोकन रहते हैं और जो स्थिर दर से भरती रहती है। हर अनुरोध एक टोकन निकालता है। बकेट खाली हो तो अनुरोध अस्वीकृत होता है। दो आँकड़े इसे पूरी तरह बता देते हैं: भरने की दर, यानी आपकी टिकाऊ क्षमता, और बकेट का आकार, यानी सबसे बड़ा बर्स्ट जिसे आप सहेंगे।

100 टोकन वाली बकेट जो प्रति सेकंड 10 भरती है, निष्क्रिय क्लाइंट को तुरंत 100 अनुरोध छोड़ने देती है और फिर उसे 10 प्रति सेकंड पर ले आती है। आमतौर पर यही चाहिए: असली क्लाइंट झटकों में आते हैं, इसलिए छोटा उछाल दुरुपयोग नहीं बल्कि सामान्य ट्रैफ़िक है, जबकि दीर्घकालिक औसत सीमित रहता है। टोकन बकेट अच्छे कारणों से डिफ़ॉल्ट है — लागू करना सस्ता है, प्रति क्लाइंट केवल टोकन गिनती और एक टाइमस्टैम्प चाहिए, और इसका व्यवहार दस्तावेज़ में समझाना आसान है।

लीकी बकेट

लीकी बकेट इसका उल्टा रूप है। अनुरोध एक कतार में आते हैं और स्थिर दर से निकलते हैं, जैसे छेद से पानी। कतार भरी हो तो नए अनुरोध अस्वीकृत होते हैं। निर्गम पूरी तरह समान रहता है, और ठीक यही उस बैकएंड के सामने चाहिए जो किसी भी उछाल को नहीं सह सकता, जैसे कोई पुरानी प्रणाली या किसी तीसरे पक्ष की API जिसे आप आगे बेचते हैं।

इसकी कीमत विलंब है। लगभग भरी कतार में आया अनुरोध जल्दी विफल होने के बजाय प्रतीक्षा करता है, और क्लाइंट धीमे सर्वर तथा कतार में लगे अनुरोध में अंतर नहीं कर पाता। किसी नाज़ुक चीज़ की ओर जाते ट्रैफ़िक को ढालने के लिए इसका उपयोग करें; अपनी लचीली सेवा की सुरक्षा के लिए टोकन बकेट बेहतर है।

फ़िक्स्ड और स्लाइडिंग विंडो

फ़िक्स्ड विंडो कैलेंडर अवधि के हिसाब से गिनती करती है: 1,000 प्रति घंटा, हर घंटे पर रीसेट। एक काउंटर और एक कुंजी से इसे बनाना बहुत आसान है, और इसमें एक सुविख्यात खामी है: सीमा-रेखा का बर्स्ट। जो क्लाइंट 10:59:59 पर 1,000 अनुरोध और 11:00:01 पर 1,000 और भेजता है, वह नीति के भीतर रहते हुए भी दो सेकंड में 2,000 अनुरोध पहुँचा देता है — आपकी इच्छित चरम सीमा का दोगुना।

स्लाइडिंग विंडो इसे सुधारती है, क्योंकि वह चालू कैलेंडर खंड के बजाय पिछली अवधि पर गिनती करती है। 11:00:01 पर वह 10:59:59 के अनुरोध अब भी देखती है और अतिरिक्त को अस्वीकार कर देती है। सटीक रूप प्रति अनुरोध एक टाइमस्टैम्प रखता है, जिसमें मेमोरी लगती है; एक आम बीच का रास्ता पिछली विंडो की गिनती को इस अनुपात में तोलता है कि उसका कितना हिस्सा अब भी ओवरलैप करता है, जो लगभग हर API के लिए पर्याप्त सटीक है और स्टेट का बहुत कम हिस्सा लेता है।

अपनी सीमाएँ कैसे चुनें

आँकड़े मापों से चुनें, उस गोल संख्या से नहीं जो उदार दिखती है। एक कारगर क्रम:

1. अपनी ऊपरी हद मापें। लोड परीक्षण तब तक करें जब तक विलंब बिगड़ने लगे। वह क्षमता, कुछ गुंजाइश घटाकर, आपकी असली क्षमता है।
2. अपेक्षित समांतर क्लाइंट से भाग दें। यह प्रति-क्लाइंट सीमा का शुरुआती बिंदु है, अंतिम उत्तर नहीं।
3. अपना वर्तमान ट्रैफ़िक देखें। प्रति क्लाइंट अनुरोध दर का 95वाँ और 99वाँ पर्सेंटाइल निकालें। 99वें पर्सेंटाइल से नीचे की सीमा वैध उपयोगकर्ताओं के कारण आपको जगाएगी।
4. बर्स्ट की गुंजाइश दें। प्रति सेकंड दर का लगभग 10 से 20 गुना आम बकेट आकार है; यह सामान्य पेज लोड सह लेता है और टिकाऊ दुरुपयोग की अनुमति नहीं देता।
5. स्तरों में बाँटें। अनाम, प्रमाणित और भुगतान करने वाले क्लाइंट एक ही सीमा साझा न करें। ऊँची हद के लिए अधिक शुल्क लेना API की कीमत तय करने का सबसे साफ़ तरीका भी है।
6. लागू करने से पहले देखें। अस्वीकार शुरू करने से पहले एक सप्ताह यह दर्ज करें कि क्या अस्वीकार हुआ होता।

आप किस आधार पर गिनते हैं, यह संख्या जितना ही मायने रखता है। अनाम ट्रैफ़िक के लिए IP ही एकमात्र विकल्प है, पर वह साझा नेटवर्क और NAT को दंडित करता है; प्रमाणित कॉल के लिए API कुंजी न्यायसंगत और सही डिफ़ॉल्ट है; खाता-आधार क्लाइंट को नई कुंजियाँ बनाकर अतिरिक्त क्षमता खरीदने से रोकता है। कई API तीनों एक साथ लगाती हैं — एक वैश्विक सीमा, प्रति कुंजी सीमा, और महँगे रास्तों पर प्रति एंडपॉइंट सीमा।

संख्या मिल जाने पर उसे अनुरोधों के अंतराल में बदलने का गणित थोड़े से अंतर से गलत होना आसान है। दर सीमा कैलकुलेटर किसी सीमा और विंडो को अनुरोधों के न्यूनतम अंतराल, सुरक्षित टिकाऊ दर, और प्रकाशित करने योग्य Retry-After मान में बदल देता है।

क्लाइंट के लिए ज़रूरी हेडर

जिस सीमा को क्लाइंट देख नहीं सकता, उसी से वह टकराएगा। अपनी स्थिति हर रिस्पॉन्स में भेजें, केवल अस्वीकृतियों में नहीं:

• RateLimit-Limit — वर्तमान विंडो की ऊपरी हद।
• RateLimit-Remaining — उसमें कितने अनुरोध बचे हैं।
• RateLimit-Reset — कोटा कब नया होगा, अब से कितने सेकंड में।
• Retry-After — 429 या 503 पर कितनी देर रुकना है। सेकंड की संख्या या HTTP तिथि।

X-RateLimit-* वाली वर्तनी अब भी व्यापक है और ठीक काम करती है; ऊपर दिए बिना उपसर्ग वाले नाम मानकीकृत रूप हैं, और बदलाव के दौरान दोनों भेजने में कोई लागत नहीं। ज़रूरी यह है कि मान मौजूद और सही हों, क्योंकि उनसे अच्छा क्लाइंट अपनी गति संभाल लेता है और 429 कभी देखता ही नहीं।

जब अस्वीकार करें तो 429 Too Many Requests लौटाएँ, कभी 403 नहीं और कभी सामान्य 500 नहीं। 429 ही एकमात्र कोड है जो क्लाइंट को बताता है कि अनुरोध ठीक था और बाद में सफल होगा, और यही संकेत सही पुनः प्रयास पैदा करता है। हमारा HTTP स्टेटस कोड संदर्भ इससे जुड़े कोड और हर कोड से क्लाइंट पर बनने वाले दायित्व बताता है।

क्लाइंट के तौर पर 429 से निपटना

कनेक्शन के दूसरी ओर के नियम छोटे हैं और लगभग हमेशा अधूरे लागू होते हैं:

1. Retry-After का पालन करें। अगर सर्वर बता रहा है कि कितनी देर रुकें, उतनी ही देर रुकें। इससे बेहतर जानकारी आपके पास कुछ नहीं है।
2. वरना गुणोत्तर क्रम में धीमा हों। 1 से, 2 से, 4 से, 8 से — एक ऊपरी हद तक। तुरंत दोबारा कोशिश करना एक अधिभार को अपने ही बनाए रेले में बदल देता है।
3. थोड़ी अनियमितता जोड़ें। हर प्रतीक्षा को कुछ सौ मिलीसेकंड तक यादृच्छिक रूप से बदलें। इसके बिना साथ विफल हुए सभी क्लाइंट साथ ही दोबारा कोशिश करते हैं, और आपकी प्रतीक्षा योजना उसी उछाल को दोहरा देती है जिसे उसे फैलाना था।
4. प्रयास सीमित रखें। तीन से पाँच बार, फिर विफलता बता दें। अनंत प्रयास असली व्यवधान छिपा देते हैं।
5. हेडर से अपनी गति तय करें। RateLimit-Remaining पढ़ें और अस्वीकृति से पहले ही धीमे हो जाएँ। यही अंतर है उस क्लाइंट में जो चलता है और उसमें जो अधिकतर समय चलता है।
6. 429 के अलावा किसी 4xx को दोबारा न आज़माएँ। 400 या 422 हर बार वैसे ही विफल होगा, क्योंकि समस्या अनुरोध में ही है।

बचने योग्य आम गलतियाँ

• 429 की जगह 403 लौटाना। क्लाइंट 403 को स्थायी मानकर रुक जाते हैं, या आँख बंद कर दोहराते हैं; दोनों ही व्यवहार आपके काम के नहीं।
• Retry-After छोड़ देना। आपने क्लाइंट से अनुमान लगाने को कहा है, और आम अनुमान «अभी» होता है।
• केवल IP के आधार पर सीमा। एक NAT पते के पीछे पूरा दफ़्तर एक क्लाइंट बन जाता है, और वितरित स्क्रैपर हज़ार।
• हर एंडपॉइंट को बराबर गिनना। कैश से हुई एक पढ़ाई और आठ सेकंड चलने वाली रिपोर्ट एक-एक टोकन की कीमत पर न हों; महँगे रास्तों को तोलें या उन्हें अलग सीमा दें।
• तंग सीमा वाली फ़िक्स्ड विंडो। सीमा-रेखा के बर्स्ट के कारण आपकी असली चरम सीमा प्रकाशित संख्या की दोगुनी हो जाती है।
• बर्स्ट की कोई गुंजाइश न रखना। पूरी तरह समान सीमा सामान्य ट्रैफ़िक अस्वीकार कर देती है, क्योंकि असली क्लाइंट झुंड में आते हैं।
• बिना दस्तावेज़ वाली सीमाएँ। अगर संख्या आपके दस्तावेज़ और हेडर में नहीं है, तो हर इंटीग्रेटर उसे प्रोडक्शन में ही जानेगा।
• अनियमितता के बिना पुनः प्रयास। एक साथ होने वाले पुनः प्रयास ही छोटे उछाल को टिकाऊ बना देते हैं।

अपनी सीमाएँ निकालें

अच्छी दर सीमा नीरस होती है: क्लाइंट आपके हेडर से अपनी गति संभालते हैं, बर्स्ट सह लिए जाते हैं, दुरुपयोग थम जाता है, और किसी को पता भी नहीं चलता। वहाँ पहुँचना मुख्य रूप से गणित और अपनी असली क्षमता के बारे में ईमानदारी है। ऐसी सीमा और विंडो से शुरू करें जिसे आप सच में टिका सकें, उसे अपने क्लाइंट के लिए ज़रूरी अंतराल और Retry-After में बदलें, दोनों प्रकाशित करें, और सीमा के करीब आने वाले मामले दर्ज करें ताकि आप बहुत तंग सीमा और बिगड़े क्लाइंट में अंतर कर सकें।

संबंधित टूल और गाइड:

• दर सीमा कैलकुलेटर — सीमा और विंडो को अंतराल, बर्स्ट आकार और Retry-After में बदलें।
• HTTP स्टेटस कोड — 429, 503 और बाकी कोड क्लाइंट से क्या चाहते हैं।
• HTTP स्टेटस कोड: पूरी गाइड — हर रिस्पॉन्स श्रेणी की व्याख्या।
• DNS लुकअप — पुष्टि करें कि आपका API ट्रैफ़िक असल में किस होस्ट तक पहुँचता है।

अक्सर पूछे जाने वाले प्रश्न