રેટ લિમિટિંગ શું છે? એપ બિલ્ડર્સ માટે સરળ ભાષામાં માર્ગદર્શિકા

રેટ લિમિટિંગ એ એક નિયમ છે જે નક્કી સમયમાં કોઈ સિસ્ટમને કેટલી વિનંતીઓ કરી શકાય તેની મર્યાદા મૂકે છે — ઉદાહરણ તરીકે, પ્રતિ મિનિટ 5 લૉગિન પ્રયાસ, અથવા પ્રતિ કલાક 100 API કૉલ. મર્યાદા પહોંચ્યા પછી, સમય વિન્ડો રીસેટ થાય ત્યાં સુધી વધુ વિનંતીઓ નકારવામાં આવે છે (સામાન્ય રીતે 429 Too Many Requests એરર કોડ સાથે). તે એપને દુરુપયોગથી બચાવે છે, એક ભારે વપરાશકર્તાને બધા માટે ધીમું પડતું અટકાવે છે, અને બેકાબૂ ખર્ચ રોકે છે.

તમે રેટ લિમિટિંગને બે બાજુથી જુઓ છો: તમે જે સેવાઓ કૉલ કરો છો તે તમને મર્યાદિત કરે છે, અને તમારી પોતાની એપે તેના વપરાશકર્તાઓને મર્યાદિત કરવા જોઈએ.

AI સાથે બનાવતી વખતે રેટ લિમિટિંગ શા માટે મહત્વનું છે

AI-બનાવેલી એપ ઘણી વાર ચૂકવણીવાળી સેવાઓ સાથે જોડાય છે — AI મૉડેલ, ઈમેલ, SMS, નકશા — અને દરેક કૉલ પૈસા ખર્ચે છે. એટલે રેટ લિમિટિંગ એક સુરક્ષા ફીચર અને બજેટ ફીચર બંને છે.

• ખર્ચ નિયંત્રણ. જો તમારી એપમાં “AI ને પૂછો” બૉક્સ હોય અને મર્યાદા ન હોય, તો એક બૉટ રાતોરાત તેને હજારો વિનંતીઓ મોકલી શકે છે. દરેક માટે તમે ચૂકવશો.
• સુરક્ષા. લૉગિન ફોર્મ પર મર્યાદા વિના, હુમલાખોર એક ખાતામાં હજારો પાસવર્ડ અજમાવી શકે છે. પ્રતિ મિનિટ થોડા પ્રયાસની મર્યાદા તે અવ્યવહારુ બનાવે છે.
• ઓનલાઈન રહેવું. એક ખોટી રીતે વર્તતી સ્ક્રિપ્ટ — ક્યારેક તમારો પોતાનો કોડ લૂપમાં અટકી જાય — તમારા ડેટાબેઝને ઓવરલોડ કરી એપ બંધ કરી શકે છે.
• અન્ય સેવાઓની મર્યાદાનું પાલન. જ્યારે તમારી એપ બહારના API ને ખૂબ વાર કૉલ કરે છે, ત્યારે તમને 429 એરર મળે છે, અને તમારા વપરાશકર્તાઓ માટે ફીચર તૂટે છે.

AI બિલ્ડર તમે માગો તે બનાવશે. જો તમે મર્યાદાનો ઉલ્લેખ ન કરો, તો તે ઘણી વાર છૂટી જાય છે.

રોજિંદા જીવનનું ઉદાહરણ

કૉફી શૉપની મફત રિફિલ નીતિ વિચારો: “દરેક ગ્રાહક માટે દરેક મુલાકાતે એક મફત રિફિલ.”

• તે કોઈને કૉફીનો આનંદ લેતા રોકતી નથી.
• તે એક વ્યક્તિને આખો દિવસ કાઉન્ટર પર ઊભા રહીને આખી ઑફિસ માટે ફ્લાસ્ક ફરી ભરાવતાં રોકે છે.
• જ્યારે કોઈ ચોથી રિફિલ માગે, ત્યારે બરિસ્ટા નમ્રતાથી કહે છે “અત્યારે નહીં” — એ જ 429 છે.

સારી રેટ લિમિટ સામાન્ય ગ્રાહકોને દેખાતી નથી અને માત્ર કંઈક અસામાન્ય કરનારને જ નડે છે.

રેટ લિમિટિંગ કેવી રીતે કામ કરે છે

રેટ લિમિટરને ત્રણ વસ્તુઓ જોઈએ:

જ્યારે વિનંતી આવે છે, ત્યારે એપ “કોણ” માટેની ગણતરી તપાસે છે. મર્યાદામાં: વિનંતી પસાર થાય છે અને ગણતરી વધે છે. મર્યાદા વટાવે: વિનંતી નકારાય છે.

ગણતરી કરવાની થોડી સામાન્ય રીતો છે:

ગણતરીઓ ઝડપી અને સહિયારા સ્ટોરમાં સંગ્રહાવી પડે. એક નાના સર્વર પર મેમરી ચાલે. એકથી વધુ મશીન પર એપ ચાલે ત્યારે કાઉન્ટર સામાન્ય રીતે Redis અથવા ડેટાબેઝ જેવા સહિયારા સ્ટોરમાં રહે છે, નહીંતર દરેક મશીન અલગ ગણતરી કરે છે અને વાસ્તવિક મર્યાદા કેટલાય ગણી વધી જાય છે.

રેટ લિમિટ થયેલો પ્રતિસાદ કેવો દેખાય છે

જ્યારે વિનંતી મર્યાદા વટાવે, ત્યારે સારી રીતે બનેલો API આવું જવાબ આપે છે:

• સ્ટેટસ કોડ 429 Too Many Requests.
• ઘણી વાર Retry-After હેડર, જે કહે છે કે કેટલા સેકન્ડ રાહ જોવી.
• કેટલીક વાર હેડર જે તમારી મર્યાદા અને આ વિન્ડોમાં કેટલી વિનંતીઓ બાકી છે તે બતાવે (નામ પ્રોવાઇડર પ્રમાણે બદલાય છે).

તમારી એપે 429 ના જવાબમાં રાહ જોઈને પછી ફરી પ્રયાસ કરવો જોઈએ — આદર્શ રીતે એક્સપોનેન્શિયલ બેકઑફ સાથે, જેનો અર્થ છે દરેક નિષ્ફળ પ્રયાસ પછી થોડી વધુ રાહ જોવી (1 સેકન્ડ, પછી 2, પછી 4), સેવા પર સતત હથોડા મારવાને બદલે.

એક કાર્યરત ઉદાહરણ: AI લેખન સહાયક

ધારો કે તમે એક એપ બનાવી છે જ્યાં વપરાશકર્તાઓ લખાણ પેસ્ટ કરે છે અને AI પાસેથી ફરીથી લખાયેલું લખાણ મેળવે છે.

મર્યાદા વિના: કોઈ એક સ્ક્રિપ્ટ રાતોરાત 20,000 વિનંતીઓ મોકલે છે. તમારું AI પ્રોવાઇડર બિલ વધી જાય છે, અને તમારું ખાતું પ્રોવાઇડરની પોતાની રેટ લિમિટ સુધી પહોંચે છે, તેથી સાચા વપરાશકર્તાઓને આખી સવાર એરર દેખાય છે.

સમજદાર મર્યાદા સાથે:

1. સાઇન-ઇન થયેલા દરેક વપરાશકર્તા દીઠ: મફત પ્લાન પર કલાકના 30 ફરીથી લખાણ, પેઇડ પર 300. મર્યાદા વટાવે ત્યારે વપરાશકર્તાને દેખાય: “તમે આ કલાકની મર્યાદા પર પહોંચ્યા છો. 12 મિનિટ પછી ફરી પ્રયાસ કરો, અથવા અપગ્રેડ કરો.”
2. સાઇન-અપ ફોર્મ પર પ્રતિ IP એડ્રેસ: કલાક દીઠ 5 સાઇન-અપ, જેથી બૉટ પ્રતિ-વપરાશકર્તા મર્યાદા ટાળવા હજારો મફત ખાતાં ન બનાવે.
3. તમારા AI પ્રોવાઇડરના ડૅશબોર્ડમાં સેટ કરેલી ખર્ચ મર્યાદા, જો બધું નિષ્ફળ જાય તો છેલ્લી રક્ષણ રેખા તરીકે.
4. પ્રોવાઇડરની મર્યાદા સંભાળવી: જો AI પ્રોવાઇડર 429 આપે, તો તમારો સર્વર રાહ જોઈને એક-બે વાર ફરી પ્રયાસ કરે, પછી “વ્યસ્ત છીએ, કૃપા કરી ફરી પ્રયાસ કરો” સંદેશ બતાવે.

મર્યાદા સર્વર પર તપાસાય છે. ફક્ત બ્રાઉઝરમાં રહેલી મર્યાદા — ઉદાહરણ તરીકે 30 ક્લિક પછી બટન બંધ કરવું — કોઈ પણ વ્યક્તિ તમારા API ને સીધો કૉલ કરીને બાયપાસ કરી શકે છે.

મુખ્ય શબ્દો

સામાન્ય ગેરસમજો

• “રેટ લિમિટિંગ ફક્ત મોટી એપ માટે છે.” નાની એપ પણ લક્ષ્ય બને છે, કારણ કે બૉટ ખુલ્લાં ફોર્મ અને AI એન્ડપૉઇન્ટ માટે આખું ઇન્ટરનેટ સ્કેન કરે છે. દુરુપયોગનો ખર્ચ તમારા કદ પર આધારિત નથી.
• “બટન છુપાવવું પૂરતું છે.” બ્રાઉઝર-બાજુની મર્યાદા એ સૌજન્ય છે, રક્ષણ નહીં. વાસ્તવિક મર્યાદા સર્વર પર લાગુ થવી જોઈએ.
• “પ્રતિ-IP મર્યાદા હંમેશા ન્યાયી હોય.” ઘણા લોકો એક IP એડ્રેસ શેર કરી શકે — ઑફિસ, શાળા, મોબાઇલ નેટવર્ક. લોકો સાઇન-ઇન થયા પછી પ્રતિ-વપરાશકર્તા મર્યાદા વધુ ન્યાયી છે.
• “429 નો અર્થ સેવા તૂટેલી છે.” તેનો અર્થ છે તમે તેને ખૂબ વાર કૉલ કરો છો. તમારા કોડમાં લૂપ તપાસો, અને જે પરિણામો ઘણી વાર બદલાતા નથી તેને કૅશ કરો — જુઓ કૅશિંગ શું છે.
• “રેટ લિમિટિંગ ખર્ચ મર્યાદાની જગ્યા લે છે.” બંને વાપરો. તમારી એપની મર્યાદામાં બગ હોઈ શકે; પ્રોવાઇડરની ખર્ચ મર્યાદા તમારો બૅકસ્ટૉપ છે.

તમારા AI બિલ્ડરને શું પૂછવું

• “લૉગિન, સાઇન-અપ, પાસવર્ડ રીસેટ અને AI એન્ડપૉઇન્ટ પર સર્વર-બાજુ રેટ લિમિટિંગ ઉમેરો. સમજદાર મર્યાદા સૂચવો.”
• “સાઇન-ઇન થયેલા દરેક વપરાશકર્તાને કલાકના [N] AI વિનંતીઓ સુધી મર્યાદિત કરો, અને મર્યાદા પહોંચે ત્યારે રાહ જોવાના સમય સાથે સ્પષ્ટ સંદેશ બતાવો.”
• “જ્યારે બહારનો API 429 આપે, ત્યારે એક્સપોનેન્શિયલ બેકઑફ સાથે વધુમાં વધુ 3 વાર ફરી પ્રયાસ કરો, પછી મૈત્રીપૂર્ણ એરર બતાવો.”
• “રેટ-લિમિટ કાઉન્ટર ક્યાં સંગ્રહાય છે? જો એપ એકથી વધુ મશીન પર ચાલે તો પણ તે કામ કરશે?”
• “જ્યારે પણ વપરાશકર્તા કે IP મર્યાદા પહોંચે ત્યારે લૉગ કરો, જેથી હું દુરુપયોગ ઓળખી શકું.”
• “આ એપ કઈ બહારની સેવાઓ કૉલ કરે છે, અને તેમની રેટ લિમિટ શું છે?”

Mythex માં રેટ લિમિટિંગ

AI ફીચર્સ માટે Mythex ના ડૉક્સ આ વિશે સીધા છે: તમે બનાવેલી એપમાં રેટ લિમિટ, સલામતી અને ખર્ચ નિયંત્રણો તમારે ડિઝાઇન કરવાના છે — જુઓ AI એપ બનાવો. ફીચર માગો તે જ સંદેશમાં એજન્ટને મર્યાદા ઉમેરવા કહો. Pro પર, ભારે ટ્રાફિકમાં પ્રકાશિત સેવા ત્રણ મશીન સુધી ચાલી શકે છે (જુઓ હોસ્ટિંગ મર્યાદા), તેથી એક સર્વરની મેમરીને બદલે ડેટાબેઝમાં રહેતા કાઉન્ટર માગો.

સંબંધિત વાંચન: API એટલે શું, LLM APIs કેવી રીતે વાપરવા અને AI-બનાવેલી એપ માટે સુરક્ષા ચેકલિસ્ટ.

પ્રશ્નો