Rate Limiting என்றால் என்ன? ஆப் உருவாக்குபவர்களுக்கான எளிய வழிகாட்டி

Rate limiting என்பது ஒருவர் ஒரு அமைப்புக்கு குறிப்பிட்ட நேரத்தில் எத்தனை கோரிக்கைகள் அனுப்பலாம் என்பதை வரையறுக்கும் விதி — உதாரணமாக ஒரு நிமிடத்தில் 5 login முயற்சிகள், அல்லது ஒரு மணி நேரத்தில் 100 API அழைப்புகள். வரம்பை எட்டியவுடன் மேலும் கோரிக்கைகள் மறுக்கப்படும் (பொதுவாக 429 Too Many Requests பிழைக் குறியீட்டுடன்), கால அளவு மீண்டும் தொடங்கும் வரை. இது ஆப்களை துஷ்பிரயோகத்திலிருந்து காக்கிறது, ஒரு அதிக பயன்படுத்தும் பயனர் எல்லோருக்கும் வேகத்தைக் குறைப்பதைத் தடுக்கிறது, கட்டுக்கடங்காத செலவுகளையும் நிறுத்துகிறது.

Rate limiting-ஐ இரண்டு பக்கங்களிலிருந்து சந்திப்பீர்கள்: நீங்கள் அழைக்கும் சேவைகள் உங்களை வரம்பிடும், உங்கள் சொந்த ஆப் அதன் பயனர்களை வரம்பிட வேண்டும்.

AI உடன் உருவாக்கும்போது rate limiting ஏன் முக்கியம்

AI-இல் உருவாக்கப்படும் ஆப்கள் பெரும்பாலும் பணம் செலுத்த வேண்டிய சேவைகளுடன் இணைகின்றன — AI மாடல்கள், email, SMS, வரைபடங்கள் — ஒவ்வொரு அழைப்பும் பணம் செலவழிக்கிறது. அதனால் rate limiting என்பது பாதுகாப்பு அம்சமாகவும் பட்ஜெட் அம்சமாகவும் இருக்கிறது.

• செலவுக் கட்டுப்பாடு. உங்கள் ஆப்பில் “AI-யிடம் கேள்” பெட்டி இருந்து வரம்பு இல்லையென்றால், ஒரு bot ஒரே இரவில் ஆயிரக்கணக்கான கோரிக்கைகளை அனுப்பலாம். ஒவ்வொன்றுக்கும் நீங்கள் பணம் செலுத்துவீர்கள்.
• பாதுகாப்பு. login படிவத்தில் வரம்பு இல்லாவிட்டால், ஒரு தாக்குபவர் ஒரு கணக்குக்கு ஆயிரக்கணக்கான கடவுச்சொற்களை முயற்சிக்கலாம். ஒரு நிமிடத்துக்கு சில முயற்சிகள் என்ற வரம்பு அதை நடைமுறையில் சாத்தியமற்றதாக்கும்.
• சேவையில் தொடர்ந்து இருத்தல். தவறாக நடக்கும் ஒரு script — சில நேரங்களில் உங்கள் சொந்தக் code ஒரு loop-இல் சிக்கிக்கொள்வது — உங்கள் database-ஐ அதிக சுமைக்கு உள்ளாக்கி ஆப்பை நிறுத்தலாம்.
• மற்ற சேவைகளின் வரம்புகளை மதித்தல். உங்கள் ஆப் வெளி API-ஐ மிக அடிக்கடி அழைத்தால், 429 பிழைகள் உங்களுக்கே வரும், உங்கள் பயனர்களுக்கு அம்சங்கள் உடையும்.

AI builder-கள் நீங்கள் கேட்பதைக் கட்டுவார்கள். வரம்புகளைப் பற்றி நீங்கள் குறிப்பிடாவிட்டால், அவை பெரும்பாலும் விடுபட்டுவிடும்.

அன்றாட உவமை

ஒரு காபிக் கடையின் இலவச refill கொள்கையை நினைத்துப் பாருங்கள்: “ஒரு வாடிக்கையாளருக்கு ஒரு வருகைக்கு ஒரு இலவச refill.”

• அது யாரும் காபியை அனுபவிப்பதைத் தடுக்காது.
• ஒருவர் நாள் முழுவதும் கவுண்டரில் நின்று முழு அலுவலகத்துக்கும் ஒரு flask நிரப்புவதைத் தடுக்கிறது.
• ஒருவர் நான்காவது refill கேட்கும்போது, பணியாளர் பணிவுடன் “இப்போது முடியாது” என்கிறார் — அதுதான் 429.

நல்ல rate limit சாதாரண வாடிக்கையாளர்களுக்குக் கண்ணுக்குத் தெரியாது; அசாதாரணமாக ஏதோ செய்பவரால் மட்டுமே கவனிக்கப்படும்.

Rate limiting எப்படி வேலை செய்கிறது

Rate limiter-க்கு மூன்று விஷயங்கள் தேவை:

ஒரு கோரிக்கை வரும்போது, ஆப் அந்த “யார்” என்பதற்கான எண்ணிக்கையைச் சரிபார்க்கிறது. வரம்புக்குள் இருந்தால்: கோரிக்கை கடந்து செல்லும், எண்ணிக்கை உயரும். வரம்பைத் தாண்டினால்: கோரிக்கை மறுக்கப்படும்.

எண்ணுவதற்கு சில பொதுவான முறைகள் உள்ளன:

எண்ணிக்கைகள் வேகமான, பகிரப்பட்ட இடத்தில் சேமிக்கப்பட வேண்டும். ஒரே சிறிய சேவையகத்தில் நினைவகம் போதும். ஆப் பல இயந்திரங்களில் ஓடத் தொடங்கியதும், counter பொதுவாக Redis அல்லது database போன்ற பகிரப்பட்ட சேமிப்பில் இருக்க வேண்டும்; இல்லையென்றால் ஒவ்வொரு இயந்திரமும் தனியாக எண்ணும், உண்மையான வரம்பு பல மடங்கு உயர்ந்துவிடும்.

வரம்பு மீறிய பதில் எப்படித் தெரியும்

கோரிக்கை வரம்பை மீறும்போது, நல்ல API இவ்வாறு பதிலளிக்கும்:

• நிலைக் குறியீடு 429 Too Many Requests.
• பெரும்பாலும் Retry-After header, எத்தனை வினாடிகள் காத்திருக்க வேண்டும் என்று.
• சில நேரங்களில் உங்கள் வரம்பையும், இந்த சாளரத்தில் இன்னும் எத்தனை கோரிக்கைகள் மீதமுள்ளன என்பதையும் காட்டும் headers (பெயர்கள் provider-க்கு provider மாறும்).

429 வந்தால் உங்கள் ஆப் காத்திருந்து பின்னர் மீண்டும் முயல வேண்டும் — முடிந்தால் exponential backoff முறையில், ஒவ்வொரு தோல்விக்குப் பின்னும் சற்று நீண்ட நேரம் காத்திருந்து (1 வினாடி, பின் 2, பின் 4), சேவையை தொடர்ந்து தட்டாமல்.

ஒரு வேலை செய்த உதாரணம்: ஒரு AI எழுத்து உதவியாளர்

பயனர்கள் உரையை ஒட்டி AI மூலம் மறுஎழுத்துப் பெறும் ஒரு ஆப்பை உருவாக்கியுள்ளீர்கள் என்று வைத்துக்கொள்ளுங்கள்.

வரம்பு இல்லாமல்: ஒருவர் ஒரே இரவில் 20,000 கோரிக்கைகள் அனுப்பும் script எழுதுகிறார். உங்கள் AI provider பில் உயர்கிறது, உங்கள் கணக்கு provider-இன் சொந்த rate limit-ஐ எட்டுகிறது, உண்மையான பயனர்கள் காலை முழுவதும் பிழைகளைப் பார்க்கிறார்கள்.

நியாயமான வரம்புகளுடன்:

1. உள்நுழைந்த பயனர் வாரியாக: இலவசத் திட்டத்தில் ஒரு மணி நேரத்துக்கு 30 மறுஎழுத்துகள், கட்டண திட்டத்தில் 300. வரம்பை மீறினால் பயனர் பார்ப்பது: “இந்த மணி நேர வரம்பை எட்டிவிட்டீர்கள். 12 நிமிடங்களில் மீண்டும் முயலுங்கள், அல்லது மேம்படுத்துங்கள்.”
2. பதிவு படிவத்தில் IP முகவரி வாரியாக: ஒரு மணி நேரத்துக்கு 5 பதிவுகள், பயனர் வாரி வரம்பைத் தவிர்க்க bot-கள் ஆயிரக்கணக்கான இலவசக் கணக்குகளை உருவாக்குவதைத் தடுக்க.
3. செலவு வரம்பு உங்கள் AI provider டாஷ்போர்டில் அமைக்கப்பட்டது, மற்ற அனைத்தும் தோல்வியுற்றால் கடைசி பாதுகாப்பாக.
4. Provider வரம்புகளைக் கையாளுதல்: AI provider 429 தந்தால், உங்கள் சேவையகம் ஒன்று அல்லது இரண்டு முறை காத்திருந்து மீண்டும் முயலும், பின்னர் “பிஸியாக உள்ளது, மீண்டும் முயலுங்கள்” என்ற நட்பான செய்தியைக் காட்டும்.

வரம்புகள் சேவையகத்தில் சரிபார்க்கப்பட வேண்டும். உலாவியில் மட்டும் உள்ள வரம்பு — உதாரணமாக 30 கிளிக்குகளுக்குப் பின் பொத்தானை முடக்குவது — உங்கள் API-ஐ நேரடியாக அழைக்கும் எவராலும் தவிர்க்கப்படலாம்.

முக்கிய சொற்கள்

பொதுவான தவறான கருத்துகள்

• “Rate limiting பெரிய ஆப்களுக்கு மட்டுமே.” சிறிய ஆப்களும் இலக்குகளாகின்றன, ஏனெனில் திறந்திருக்கும் படிவங்கள் மற்றும் AI endpoints-களைத் தேடி bot-கள் இணையம் முழுவதும் ஸ்கேன் செய்கின்றன. துஷ்பிரயோகத்தின் செலவு உங்கள் அளவைப் பொறுத்தது அல்ல.
• “பொத்தானை மறைத்தால் போதும்.” உலாவி பக்க வரம்புகள் ஒரு மரியாதை, பாதுகாப்பு அல்ல. உண்மையான வரம்புகள் சேவையகத்தில் அமல்படுத்தப்பட வேண்டும்.
• “IP வாரியான வரம்புகள் எப்போதும் நியாயமானவை.” பலர் ஒரே IP முகவரியைப் பகிரலாம் — ஓர் அலுவலகம், ஒரு பள்ளி, ஒரு கைப்பேசி வலையமைப்பு. மக்கள் உள்நுழைந்த பின் பயனர் வாரி வரம்புகள் நியாயமானவை.
• “429 என்றால் சேவை உடைந்துவிட்டது.” அதன் பொருள் நீங்கள் அதை மிக அடிக்கடி அழைக்கிறீர்கள் என்பதே. உங்கள் code-இல் loops இருக்கிறதா என்று பாருங்கள், அடிக்கடி மாறாத முடிவுகளை cache செய்யுங்கள் — caching என்றால் என்ன பாருங்கள்.
• “Rate limiting செலவு வரம்பை மாற்றிவிடும்.” இரண்டையும் பயன்படுத்துங்கள். ஆப்பில் உள்ள வரம்புகளில் பிழைகள் இருக்கலாம்; provider-இன் செலவு வரம்புதான் உங்கள் கடைசி பாதுகாப்பு.

உங்கள் AI builder-இடம் என்ன கேட்பது

• “login, sign-up, password reset மற்றும் AI endpoint-க்கு சேவையக நிலையில் rate limiting சேர்க்கவும். நியாயமான வரம்புகளைப் பரிந்துரைக்கவும்.”
• “உள்நுழைந்த ஒவ்வொரு பயனரும் ஒரு மணி நேரத்துக்கு [N] AI கோரிக்கைகள் மட்டுமே அனுப்பலாம்; வரம்பை எட்டும்போது காத்திருக்கும் நேரத்துடன் தெளிவான செய்தியைக் காட்டவும்.”
• “வெளி API 429 தந்தால், 3 முறை வரை exponential backoff-உடன் மீண்டும் முயன்று, பின்னர் நட்பான பிழையைக் காட்டவும்.”
• “Rate-limit counters எங்கே சேமிக்கப்படுகின்றன? ஆப் ஒன்றுக்கு மேற்பட்ட இயந்திரங்களில் ஓடினால் அவை இன்னும் வேலை செய்யுமா?”
• “எந்தப் பயனர் அல்லது IP வரம்பை எட்டினாலும் பதிவு செய்யவும், துஷ்பிரயோகத்தைக் கண்டறிய முடியும்.”
• “இந்த ஆப் எந்த வெளி சேவைகளை அழைக்கிறது, அவற்றின் rate limits என்ன?”

Mythex-இல் rate limiting

AI அம்சங்களுக்கு Mythex-இன் docs இதில் நேரடியாக உள்ளன: நீங்கள் உருவாக்கும் ஆப்களில் rate limits, பாதுகாப்பு மற்றும் செலவுக் கட்டுப்பாடுகள் உங்கள் வடிவமைப்பு பொறுப்பு — AI ஆப் உருவாக்குவது பாருங்கள். அம்சத்தைக் கேட்கும் அதே செய்தியிலேயே வரம்புகளையும் சேர்க்கச் agent-இடம் கேளுங்கள். Pro-இல், கடுமையான போக்குவரத்தின்போது வெளியிடப்பட்ட சேவை மூன்று இயந்திரங்கள் வரை ஓடலாம் (ஹோஸ்டிங் வரம்புகள் பார்க்கவும்), எனவே ஒரு சேவையகத்தின் நினைவகத்தில் அல்லாமல் database-இல் வாழும் counters வேண்டும் என்று கேளுங்கள்.

தொடர்புடைய வாசிப்பு: API என்றால் என்ன, LLM APIs-ஐ எப்படிப் பயன்படுத்துவது, மற்றும் AI-built ஆப்களுக்கான பாதுகாப்புச் சரிபட்டியல்.

கேள்விகள்