Ce este rate limiting-ul? Un ghid simplu pentru constructorii de aplicații

Rate limiting-ul este o regulă care limitează câte cereri poate face cineva către un sistem într-o perioadă stabilită — de exemplu, 5 încercări de autentificare pe minut sau 100 de apeluri API pe oră. Odată atinsă limita, cererile suplimentare sunt refuzate (de obicei cu codul de eroare 429 Too Many Requests) până se resetează intervalul de timp. Protejează aplicațiile de abuz, împiedică un singur utilizator intens să încetinească lucrurile pentru toți și oprește costurile care scapă de sub control.

Intri în contact cu rate limiting-ul din două direcții: serviciile pe care le apelezi te limitează pe tine, iar propria ta aplicație ar trebui să își limiteze utilizatorii.

De ce contează rate limiting-ul când construiești cu AI

Aplicațiile construite cu AI se conectează adesea la servicii plătite — modele AI, e-mail, SMS, hărți — iar fiecare apel costă bani. Asta face din rate limiting atât o funcție de securitate, cât și una de buget.

• Controlul costurilor. Dacă aplicația ta are o casetă „întreabă AI” și nicio limită, un bot poate trimite mii de cereri peste noapte. Plătești pentru fiecare.
• Securitate. Fără o limită pe formularul de autentificare, un atacator poate încerca mii de parole pe un cont. O limită de câteva încercări pe minut face asta impracticabil.
• Rămânerea online. Un singur script care se comportă greșit — uneori chiar codul tău blocat într-o buclă — poate supraîncărca baza de date și poate scoate aplicația din uz.
• Respectarea limitelor altor servicii. Când aplicația ta apelează prea des un API extern, tu primești erori 429, iar funcțiile se strică pentru utilizatorii tăi.

Constructorii AI construiesc ce le ceri. Dacă nu menționezi limitele, adesea lipsesc.

O analogie din viața de zi cu zi

Gândește-te la politica de reumplere gratuită a unei cafenele: „O reumplere gratuită per client, per vizită.”

• Nu îi împiedică pe oameni să se bucure de cafea.
• Îl împiedică pe cineva să stea la tejghea toată ziua reumplând un termos pentru tot biroul.
• Când cineva cere a patra reumplere, barista spune politicos „nu acum” — asta este 429.

O limită bună este invizibilă pentru clienții normali și observată doar la cineva care face ceva neobișnuit.

Cum funcționează rate limiting-ul

Un limitator de rată are nevoie de trei lucruri:

Când sosește o cerere, aplicația verifică numărul pentru acel „cine”. Sub limită: cererea trece și numărul crește. Peste limită: cererea este refuzată.

Există câteva moduri comune de numărare:

Numărătoarele trebuie stocate undeva rapid și partajat. Pe un server mic, memoria este suficientă. Odată ce aplicația rulează pe mai multe mașini, numărătorul trăiește de obicei într-un depozit comun, ca Redis sau baza de date; altfel fiecare mașină numără separat, iar limita reală devine de câteva ori mai mare.

Cum arată un răspuns cu limită atinsă

Când o cerere depășește limita, un API bine făcut răspunde cu:

• Codul de stare 429 Too Many Requests.
• De multe ori un antet Retry-After, care spune câte secunde să aștepți.
• Uneori antete care arată limita ta și câte cereri mai ai în acest interval (denumirile variază de la furnizor la furnizor).

Aplicația ta ar trebui să răspundă unui 429 așteptând și reîncercând mai târziu — idealmente cu exponential backoff, adică așteptând puțin mai mult după fiecare încercare eșuată (1 secundă, apoi 2, apoi 4), în loc să lovească serviciul în continuu.

Un exemplu lucrat: un asistent AI de scriere

Să spunem că ai construit o aplicație în care utilizatorii lipesc text și primesc o rescriere făcută de AI.

Fără limite: cineva scrie un script care trimite 20.000 de cereri peste noapte. Factura furnizorului AI crește, iar contul tău atinge limita de rată a furnizorului, așa că utilizatorii reali văd erori toată dimineața.

Cu limite sensibile:

1. Per utilizator autentificat: 30 de rescrieri pe oră în planul gratuit, 300 în cel plătit. Peste limită, utilizatorul vede: „Ai atins limita acestei ore. Încearcă din nou peste 12 minute sau fă upgrade.”
2. Per adresă IP pe formularul de înregistrare: 5 înregistrări pe oră, ca să oprească boții care creează mii de conturi gratuite pentru a ocoli limita per utilizator.
3. O limită de cheltuieli setată în panoul furnizorului AI, ca ultimă linie de apărare dacă tot restul eșuează.
4. Gestionarea limitelor furnizorului: dacă furnizorul AI returnează un 429, serverul tău așteaptă și reîncearcă o dată sau de două ori, apoi afișează un mesaj prietenos de tipul „ocupat, încearcă din nou”.

Limitele se verifică pe server. O limită care există doar în browser — de exemplu, dezactivarea butonului după 30 de clicuri — poate fi ocolită de oricine apelează direct API-ul tău.

Termeni cheie

Idei greșite frecvente

• „Rate limiting-ul este doar pentru aplicațiile mari.” Aplicațiile mici sunt și ele ținte, pentru că boții scanează tot internetul în căutare de formulare și endpoint-uri AI deschise. Costul abuzului nu depinde de mărimea ta.
• „Ascunderea butonului este suficientă.” Limitele din browser sunt o curtoazie, nu protecție. Limitele reale trebuie aplicate pe server.
• „Limitele pe IP sunt întotdeauna corecte.” Mulți oameni pot împărți aceeași adresă IP — un birou, o școală, o rețea mobilă. Limitele pe utilizator sunt mai corecte odată ce oamenii sunt autentificați.
• „O eroare 429 înseamnă că serviciul e defect.” Înseamnă că îl apelezi prea des. Verifică-ți codul pentru bucle și salvează în cache rezultatele care nu se schimbă des — vezi ce este caching-ul.
• „Rate limiting-ul înlocuiește o limită de cheltuieli.” Folosește amândouă. Limitele din aplicație pot avea erori; limita de cheltuieli a furnizorului este plasa ta de siguranță.

Ce să ceri constructorului tău AI

• „Adaugă rate limiting pe server pentru autentificare, înregistrare, resetarea parolei și endpoint-ul AI. Sugerează limite rezonabile.”
• „Limitează fiecare utilizator autentificat la [N] cereri AI pe oră și afișează un mesaj clar cu timpul de așteptare când atinge limita.”
• „Când un API extern returnează 429, reîncearcă cu exponential backoff de până la 3 ori, apoi afișează o eroare prietenoasă.”
• „Unde sunt stocate numărătoarele de limită? Vor funcționa în continuare dacă aplicația rulează pe mai multe mașini?”
• „Înregistrează de fiecare dată când un utilizator sau o IP atinge o limită, ca să pot observa abuzul.”
• „Ce servicii externe apelează această aplicație și care sunt limitele lor?”

Rate limiting în Mythex

Documentația Mythex este directă în privința asta pentru funcțiile AI: limitele de rată, siguranța și controlul costurilor din aplicațiile pe care le construiești țin de tine să le proiectezi — vezi Construiește o aplicație AI. Cere agentului să adauge limite în același mesaj în care ceri funcția. Pe Pro, un serviciu publicat poate rula pe până la trei mașini când traficul este mare (vezi Limitele de hosting), așa că cere contoare care trăiesc în baza de date, nu în memoria unui singur server.

Lectură asemănătoare: ce este un API, cum folosești API-urile LLM și lista de verificare de securitate pentru aplicațiile construite cu AI.

Întrebări