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