रेट लिमिटिंग क्या है? ऐप बनाने वालों के लिए सरल भाषा में गाइड
रेट लिमिटिंग एक नियम है जो तय समय में किसी सिस्टम पर कोई कितने अनुरोध कर सकता है, इस पर सीमा लगाता है, जैसे प्रति मिनट 5 लॉगिन प्रयास, या प्रति घंटे 100 API कॉल। सीमा पूरी होने के बाद आगे के अनुरोध ठुकरा दिए जाते हैं (आम तौर पर 429 Too Many Requests एरर कोड के साथ) जब तक समय की खिड़की रीसेट नहीं होती। यह ऐप को दुरुपयोग से बचाती है, एक भारी उपयोगकर्ता को सबके लिए धीमा होने से रोकती है, और बेकाबू लागत को रोकती है।
रेट लिमिटिंग से आप दो तरफ़ से मिलते हैं: वे सेवाएँ जिन्हें आप बुलाते हैं आपको सीमित करती हैं, और आपका अपना ऐप अपने उपयोगकर्ताओं को सीमित करना चाहिए।
AI के साथ बनाते समय रेट लिमिटिंग क्यों मायने रखती है
AI से बने ऐप अक्सर भुगतान वाली सेवाओं से जुड़ते हैं, जैसे AI मॉडल, ईमेल, SMS, मैप, और हर कॉल पैसे खर्च करती है। इसलिए रेट लिमिटिंग सुरक्षा का भी फ़ीचर है और बजट का भी।
- लागत नियंत्रण। अगर आपके ऐप में "AI से पूछें" बॉक्स है और कोई सीमा नहीं, तो एक बॉट रात भर में उस पर हज़ारों अनुरोध भेज सकता है। हर एक का भुगतान आपको करना होगा।
- सुरक्षा। लॉगिन फ़ॉर्म पर सीमा न हो, तो हमलावर एक खाते पर हज़ारों पासवर्ड आज़मा सकता है। प्रति मिनट कुछ प्रयासों की सीमा इसे अव्यावहारिक बना देती है।
- ऑनलाइन बने रहना। एक गड़बड़ स्क्रिप्ट, कभी-कभी आपका अपना कोड जो लूप में फँस गया हो, आपके डेटाबेस को ओवरलोड कर सकता है और ऐप बंद कर सकता है।
- दूसरी सेवाओं की सीमाओं का सम्मान। जब आपका ऐप किसी बाहरी API को बहुत बार बुलाता है, तो 429 एरर आपको मिलते हैं, और आपके उपयोगकर्ताओं के फ़ीचर टूटते हैं।
AI बिल्डर वही बनाते हैं जो आप माँगते हैं। अगर आप सीमाओं का ज़िक्र नहीं करते, तो वे अक्सर छूट जाती हैं।
रोज़मर्रा की एक मिसाल
एक कॉफ़ी शॉप की मुफ़्त रीफ़िल नीति सोचिए: "हर ग्राहक को हर विज़िट पर एक मुफ़्त रीफ़िल।"
- इससे किसी को कॉफ़ी का मज़ा लेने से नहीं रोका जाता।
- यह एक व्यक्ति को दिन भर काउंटर पर खड़े होकर पूरे दफ़्तर के लिए फ़्लास्क भरवाने से रोकती है।
- जब कोई चौथी रीफ़िल माँगता है, तो बरिस्ता विनम्रता से कहता है "अभी नहीं" — यही
429है।
अच्छी रेट लिमिट सामान्य ग्राहकों को महसूस नहीं होती और सिर्फ़ किसी असामान्य काम करने वाले को दिखती है।
रेट लिमिटिंग कैसे काम करती है
एक रेट लिमिटर को तीन चीज़ें चाहिए:
| हिस्सा | यह किस सवाल का जवाब देता है | उदाहरण |
|---|---|---|
| किसके | किसके अनुरोध गिने जा रहे हैं? | प्रति उपयोगकर्ता खाता, प्रति IP पता, प्रति API कुंजी |
| कितने | सीमा क्या है? | 5, 60, 1,000 अनुरोध |
| किस समय में | किस खिड़की में? | प्रति सेकंड, मिनट, घंटा, दिन |
जब कोई अनुरोध आता है, तो ऐप उस "किसके" की गिनती जाँचता है। सीमा के भीतर हो: अनुरोध आगे जाता है और गिनती बढ़ती है। सीमा से ऊपर हो: अनुरोध ठुकरा दिया जाता है।
गिनने के कुछ आम तरीके हैं:
| तरीका | यह कैसे काम करता है | समझौता |
|---|---|---|
| फ़िक्स्ड विंडो | घड़ी के हिसाब से गिनती रीसेट होती है, जैसे हर मिनट के शुरू में | सरल, पर दो खिड़कियों के जोड़ पर एक साथ ज़्यादा अनुरोध की छूट देती है |
| स्लाइडिंग विंडो | अभी से पिछले 60 सेकंड देखती है | ज़्यादा सहज, गणना में थोड़ा ज़्यादा काम |
| टोकन बकेट | हर उपयोगकर्ता की एक बकेट होती है जो स्थिर दर से भरती है; हर अनुरोध एक टोकन लेता है | छोटे उछाल की छूट देती है और औसत स्थिर रखती है |
गिनती को कहीं तेज़ और साझा जगह पर रखना होता है। एक छोटे सर्वर पर मेमोरी काफ़ी है। जब ऐप कई मशीनों पर चलता है, तो काउंटर आम तौर पर Redis जैसे साझा स्टोर या डेटाबेस में रहता है, वरना हर मशीन अलग गिनती करेगी और असली सीमा कई गुना बढ़ जाएगी।
सीमा लगने पर जवाब कैसा दिखता है
जब कोई अनुरोध सीमा से ऊपर होता है, तो एक ठीक से बना API इस तरह जवाब देता है:
- स्टेटस कोड
429 Too Many Requests। - अक्सर एक
Retry-Afterहेडर, जो बताता है कि कितने सेकंड इंतज़ार करना है। - कभी-कभी हेडर जो दिखाते हैं कि आपकी सीमा क्या है और इस खिड़की में कितने अनुरोध बचे हैं (नाम प्रोवाइडर के हिसाब से अलग होते हैं)।
आपके ऐप को 429 पर इंतज़ार करके बाद में दोबारा कोशिश करनी चाहिए, आदर्श रूप से एक्सपोनेंशियल बैकऑफ़ के साथ, यानी हर असफल कोशिश के बाद थोड़ा और लंबा इंतज़ार (1 सेकंड, फिर 2, फिर 4), सेवा पर बार-बार हथौड़ा चलाने के बजाय।
एक उदाहरण: AI राइटिंग असिस्टेंट
मान लीजिए आपने एक ऐप बनाया है जहाँ उपयोगकर्ता टेक्स्ट चिपकाते हैं और AI से उसका नया रूप पाते हैं।
बिना सीमा के: कोई एक स्क्रिप्ट लिखता है जो रात भर में 20,000 अनुरोध भेजती है। आपका AI प्रोवाइडर का बिल बढ़ जाता है, और आपका खाता प्रोवाइडर की अपनी रेट लिमिट तक पहुँच जाता है, इसलिए असली उपयोगकर्ता पूरी सुबह एरर देखते हैं।
समझदारी भरी सीमाओं के साथ:
- साइन-इन उपयोगकर्ता के हिसाब से: मुफ़्त प्लान पर प्रति घंटे 30 रीराइट, पेड प्लान पर 300। सीमा से ऊपर उपयोगकर्ता देखता है: "आपने इस घंटे की सीमा पूरी कर ली है। 12 मिनट बाद फिर कोशिश करें, या अपग्रेड करें।"
- साइन-अप फ़ॉर्म पर प्रति IP पता: प्रति घंटे 5 साइन-अप, ताकि बॉट प्रति-उपयोगकर्ता सीमा से बचने के लिए हज़ारों मुफ़्त खाते न बना सकें।
- AI प्रोवाइडर के डैशबोर्ड में खर्च की सीमा, अगर बाकी सब फेल हो जाए तो आख़िरी सुरक्षा पंक्ति के रूप में।
- प्रोवाइडर की सीमाओं को संभालना: अगर AI प्रोवाइडर 429 लौटाए, तो आपका सर्वर एक या दो बार इंतज़ार करके फिर कोशिश करता है, फिर एक मैत्रीपूर्ण "व्यस्त हैं, कृपया फिर कोशिश करें" संदेश दिखाता है।
सीमाएँ सर्वर पर जाँची जाती हैं। सिर्फ़ ब्राउज़र में मौजूद सीमा, जैसे 30 क्लिक के बाद बटन बंद कर देना, किसी के भी द्वारा बायपास की जा सकती है जो आपके API को सीधे बुलाता है।
मुख्य शब्द
| शब्द | मतलब |
|---|---|
| Rate limit | किसी समय खिड़की में अनुमत अधिकतम अनुरोध। |
| Quota | बड़ी अनुमति, अक्सर प्रति दिन या प्रति माह, कभी-कभी पेड प्लान से जुड़ी। |
| 429 | "बहुत ज़्यादा अनुरोध" के लिए HTTP स्टेटस कोड। |
| Retry-After | एक रिस्पॉन्स हेडर जो बताता है कि दोबारा कोशिश से पहले कितनी देर रुकना है। |
| Throttling | सीमा से ऊपर के अनुरोधों को धीमा करना या ठुकराना। अक्सर इसका समानार्थी के रूप में इस्तेमाल होता है। |
| Exponential backoff | दोबारा कोशिशों के बीच धीरे-धीरे लंबा इंतज़ार करना। |
| Burst | एक साथ बहुत सारे अनुरोधों का छोटा उछाल। |
| Brute-force attack | तब तक बहुत सारे पासवर्ड या कोड आज़माते रहना जब तक कोई एक काम न करे। |
आम गलतफ़हमियाँ
- "रेट लिमिटिंग सिर्फ़ बड़े ऐप के लिए होती है।" छोटे ऐप भी निशाने पर होते हैं, क्योंकि बॉट खुले फ़ॉर्म और AI एंडपॉइंट के लिए पूरे इंटरनेट को स्कैन करते हैं। दुरुपयोग की लागत आपके आकार पर निर्भर नहीं करती।
- "बटन छिपाना काफ़ी है।" ब्राउज़र-साइड सीमाएँ सुविधा हैं, सुरक्षा नहीं। असली सीमाएँ सर्वर पर लागू होनी चाहिए।
- "प्रति-IP सीमाएँ हमेशा निष्पक्ष होती हैं।" एक IP पते को बहुत से लोग साझा कर सकते हैं: एक दफ़्तर, एक स्कूल, एक मोबाइल नेटवर्क। लोगों के साइन-इन होने के बाद प्रति-उपयोगकर्ता सीमाएँ ज़्यादा निष्पक्ष होती हैं।
- "429 का मतलब है सेवा टूटी हुई है।" इसका मतलब है कि आप उसे बहुत बार बुला रहे हैं। अपने कोड में लूप जाँचें, और जो नतीजे अक्सर नहीं बदलते उन्हें कैश करें, देखें कैशिंग क्या है।
- "रेट लिमिटिंग खर्च की सीमा की जगह ले लेती है।" दोनों इस्तेमाल करें। आपके ऐप की सीमाओं में बग हो सकते हैं; प्रोवाइडर की खर्च सीमा आपका बैकस्टॉप है।
अपने AI बिल्डर से क्या माँगें
- "लॉगिन, साइन-अप, पासवर्ड रीसेट और AI एंडपॉइंट पर सर्वर-साइड रेट लिमिटिंग जोड़ो। समझदारी भरी सीमाएँ सुझाओ।"
- "हर साइन-इन उपयोगकर्ता को प्रति घंटे [N] AI अनुरोध तक सीमित करो, और सीमा पूरी होने पर इंतज़ार के समय वाला साफ़ संदेश दिखाओ।"
- "जब कोई बाहरी API 429 लौटाए, तो एक्सपोनेंशियल बैकऑफ़ के साथ अधिकतम 3 बार दोबारा कोशिश करो, फिर एक मैत्रीपूर्ण एरर दिखाओ।"
- "रेट-लिमिट काउंटर कहाँ store होते हैं? अगर ऐप एक से ज़्यादा मशीनों पर चले तो क्या वे तब भी काम करेंगे?"
- "जब भी कोई उपयोगकर्ता या IP सीमा तक पहुँचे, उसे लॉग करो, ताकि मैं दुरुपयोग पहचान सकूँ।"
- "यह ऐप कौन सी बाहरी सेवाएँ बुलाता है, और उनकी रेट लिमिट क्या है?"
Mythex में रेट लिमिटिंग
AI फ़ीचर के लिए Mythex के डॉक्स इस पर साफ़ हैं: आपके बनाए ऐप में रेट लिमिट, सुरक्षा और लागत नियंत्रण आपके डिज़ाइन करने की चीज़ें हैं, देखें AI ऐप बनाना। फ़ीचर माँगने वाले उसी संदेश में एजेंट से सीमाएँ जोड़ने को कहें। Pro पर, भारी ट्रैफ़िक के समय एक प्रकाशित सेवा तीन मशीनों तक चल सकती है (देखें होस्टिंग सीमाएँ), इसलिए ऐसे काउंटर माँगें जो एक सर्वर की मेमोरी में नहीं, डेटाबेस में रहें।
संबंधित पढ़ाई: API क्या है, LLM API का इस्तेमाल कैसे करें और AI से बने ऐप्स के लिए सुरक्षा चेकलिस्ट।
सवाल
सरल शब्दों में रेट लिमिटिंग क्या है?
रेट लिमिटिंग एक नियम है जो तय समय में कोई उपयोगकर्ता, डिवाइस या ऐप कितने अनुरोध कर सकता है, इस पर सीमा लगाता है, जैसे प्रति मिनट 5 लॉगिन प्रयास या प्रति घंटे 100 API कॉल। सीमा से ऊपर के अनुरोध तब तक ठुकरा दिए जाते हैं जब तक समय की खिड़की रीसेट नहीं होती।
429 Too Many Requests एरर का क्या मतलब है?
HTTP स्टेटस 429 का मतलब है कि आपने बहुत कम समय में बहुत सारे अनुरोध भेज दिए और रेट लिमिट तक पहुँच गए। जवाब में अक्सर Retry-After हेडर होता है, जो बताता है कि कितनी देर इंतज़ार करना है। इसका हल है धीमे होना, कुछ देर रुककर दोबारा कोशिश करना, या यह कम करना कि आपका ऐप उस सेवा को कितनी बार बुलाता है।
मेरे AI-संचालित ऐप को रेट लिमिटिंग की ज़रूरत क्यों है?
हर AI अनुरोध टोकन के रूप में आपका पैसा खर्च करता है। बिना सीमा के, एक उपयोगकर्ता या कोई बॉट हज़ारों अनुरोध भेजकर बड़ा बिल बना सकता है या आपका प्रोवाइडर कोटा खत्म कर सकता है, और फिर सभी के लिए फ़ीचर बंद हो सकता है। प्रति-उपयोगकर्ता सीमाएँ लागत को अनुमान योग्य रखती हैं।
क्या रेट लिमिटिंग और थ्रॉटलिंग एक ही चीज़ है?
ये आपस में गहराई से जुड़े हैं और अक्सर एक-दूसरे की जगह इस्तेमाल होते हैं। रेट लिमिटिंग का आम तौर पर मतलब होता है सीमा से ऊपर के अनुरोध ठुकराना, जबकि थ्रॉटलिंग का मतलब यह भी हो सकता है कि उन्हें ठुकराने के बजाय धीमा करना या कतार में रखना।
क्या रेट लिमिटिंग DDoS हमलों को रोकती है?
यह छोटी बाढ़ जैसे हमलों और अलग-अलग उपयोगकर्ताओं या IP पतों के दुरुपयोग के खिलाफ मदद करती है, लेकिन बड़ा वितरित हमला एक साथ कई पतों से आता है। इनके खिलाफ सुरक्षा आम तौर पर नेटवर्क या CDN स्तर पर होती है, ट्रैफ़िक आपके ऐप तक पहुँचने से पहले।