Czym jest rate limiting? Prosty przewodnik dla twórców aplikacji

Rate limiting to reguła ograniczająca, ile żądań ktoś może wysłać do systemu w określonym czasie — na przykład 5 prób logowania na minutę albo 100 wywołań API na godzinę. Gdy limit zostanie osiągnięty, kolejne żądania są odrzucane (zwykle z kodem błędu 429 Too Many Requests) aż do zresetowania okna czasowego. Chroni aplikacje przed nadużyciami, nie pozwala jednemu ciężkiemu użytkownikowi spowalniać działania dla wszystkich i zapobiega niekontrolowanym kosztom.

Z rate limitingiem spotykasz się z dwóch stron: usługi, które wywołujesz, ograniczają Ciebie, a Twoja własna aplikacja powinna ograniczać jej użytkowników.

Dlaczego rate limiting ma znaczenie, gdy budujesz z AI

Aplikacje budowane z AI często łączą się z płatnymi usługami — modelami AI, e-mailem, SMS-ami, mapami — a każde wywołanie kosztuje. Dlatego rate limiting jest jednocześnie funkcją bezpieczeństwa i funkcją kontroli budżetu.

• Kontrola kosztów. Jeśli Twoja aplikacja ma pole „zapytaj AI” i nie ma limitu, bot może wysłać do niego tysiące żądań przez noc. Płacisz za każde z nich.
• Bezpieczeństwo. Bez limitu na formularzu logowania atakujący może wypróbować tysiące haseł na jednym koncie. Limit kilku prób na minutę czyni to niepraktycznym.
• Utrzymanie działania. Jeden źle działający skrypt — czasem Twój własny kod zapętlony — może przeciążyć bazę danych i położyć aplikację.
• Respektowanie limitów innych usług. Gdy Twoja aplikacja zbyt często odpytuje zewnętrzne API, to Ty dostajesz błędy 429, a funkcje psują się u Twoich użytkowników.

Narzędzia AI zbudują to, o co poprosisz. Jeśli nie wspomnisz o limitach, często zostaną pominięte.

Przykład z życia

Pomyśl o zasadzie dolewek w kawiarni: „Jedna darmowa dolewka na klienta podczas jednej wizyty”.

• Nie zabrania nikomu cieszyć się kawą.
• Powstrzymuje jedną osobę przed staniem przy ladzie i dolewaniu termosu dla całego biura.
• Gdy ktoś poprosi o czwartą dolewkę, barista uprzejmie mówi „nie teraz” — to właśnie 429.

Dobry limit jest niewidoczny dla zwykłych klientów i zauważalny tylko dla kogoś, kto robi coś nietypowego.

Jak działa rate limiting

Ogranicznik potrzebuje trzech rzeczy:

Gdy przychodzi żądanie, aplikacja sprawdza licznik dla tego „kto”. Poniżej limitu: żądanie przechodzi, a licznik rośnie. Powyżej limitu: żądanie zostaje odrzucone.

Istnieje kilka popularnych sposobów liczenia:

Liczniki muszą być przechowywane w szybkim, współdzielonym miejscu. Na jednym małym serwerze wystarczy pamięć. Gdy aplikacja działa na kilku maszynach, licznik zwykle trafia do współdzielonego magazynu, jak Redis lub baza danych — inaczej każda maszyna liczy osobno i realny limit okazuje się kilka razy wyższy.

Jak wygląda odpowiedź po przekroczeniu limitu

Gdy żądanie przekracza limit, dobrze zaprojektowane API odpowiada:

• Kodem statusu 429 Too Many Requests.
• Często nagłówkiem Retry-After z liczbą sekund do czekania.
• Czasem nagłówkami pokazującymi limit i to, ile żądań zostało w tym oknie (nazwy zależą od dostawcy).

Twoja aplikacja powinna na 429 odpowiedzieć czekaniem i ponowieniem później — najlepiej z exponential backoff, czyli czekaniem coraz dłużej po każdej nieudanej próbie (1 sekunda, potem 2, potem 4), zamiast walenia w usługę bez przerwy.

Przykład: asystent pisania z AI

Załóżmy, że zbudowałeś aplikację, w której użytkownicy wklejają tekst i dostają jego przeredagowanie przez AI.

Bez limitów: ktoś pisze skrypt, który wysyła 20 000 żądań przez noc. Rachunek u dostawcy AI rośnie, a Twoje konto trafia w limit dostawcy, więc prawdziwi użytkownicy widzą błędy przez cały ranek.

Z sensownymi limitami:

1. Per zalogowany użytkownik: 30 przeredagowań na godzinę w planie darmowym, 300 w płatnym. Po przekroczeniu użytkownik widzi: „Osiągnąłeś limit na tę godzinę. Spróbuj ponownie za 12 minut albo przejdź na wyższy plan.”
2. Per adres IP w formularzu rejestracji: 5 rejestracji na godzinę, żeby boty nie tworzyły tysięcy darmowych kont, by obejść limit per użytkownik.
3. Limit wydatków ustawiony w panelu dostawcy AI jako ostatnia linia obrony, gdyby wszystko inne zawiodło.
4. Obsługa limitów dostawcy: gdy dostawca AI zwróci 429, Twój serwer czeka i ponawia próbę raz lub dwa, a potem pokazuje przyjazny komunikat „jesteśmy zajęci, spróbuj ponownie”.

Limity sprawdza się na serwerze. Limit istniejący tylko w przeglądarce — na przykład wyłączenie przycisku po 30 kliknięciach — można obejść, wywołując API bezpośrednio.

Kluczowe pojęcia

Częste nieporozumienia

• „Rate limiting jest tylko dla dużych aplikacji.” Małe aplikacje też są celem, bo boty przeszukują internet w poszukiwaniu otwartych formularzy i endpointów AI. Koszt nadużycia nie zależy od wielkości aplikacji.
• „Wystarczy ukryć przycisk.” Ograniczenia po stronie przeglądarki to uprzejmość, a nie ochrona. Prawdziwe limity muszą być wymuszane na serwerze.
• „Limity per IP są zawsze sprawiedliwe.” Wiele osób może dzielić jeden adres IP — biuro, szkoła, sieć komórkowa. Gdy ludzie są zalogowani, limity per użytkownik są uczciwsze.
• „429 oznacza, że usługa jest zepsuta.” Oznacza, że wywołujesz ją zbyt często. Sprawdź kod pod kątem pętli i buforuj wyniki, które rzadko się zmieniają — zobacz czym jest caching.
• „Rate limiting zastępuje limit wydatków.” Używaj obu. Limity w aplikacji mogą mieć błędy; limit wydatków u dostawcy to Twoja siatka bezpieczeństwa.

Czego zapytać swojego narzędzia AI do budowania

• „Dodaj po stronie serwera rate limiting do logowania, rejestracji, resetu hasła i endpointu AI. Zaproponuj rozsądne limity.”
• „Ogranicz każdego zalogowanego użytkownika do [N] żądań AI na godzinę i pokaż jasny komunikat z czasem oczekiwania, gdy to przekroczy.”
• „Gdy zewnętrzne API zwróci 429, ponawiaj z exponential backoff do 3 razy, a potem pokaż przyjazny błąd.”
• „Gdzie są przechowywane liczniki limitów? Czy będą działać, jeśli aplikacja pójdzie na kilku maszynach?”
• „Zapisuj w logu, gdy użytkownik albo IP trafi w limit, żebym mógł wykrywać nadużycia.”
• „Z jakich zewnętrznych usług korzysta ta aplikacja i jakie są ich limity?”

Rate limiting w Mythex

Dokumentacja Mythex jest w tej kwestii jednoznaczna w przypadku funkcji AI: limity żądań, bezpieczeństwo i kontrola kosztów w aplikacjach, które budujesz, są Twoją sprawą — zobacz Budowanie aplikacji AI. Poproś agenta o dodanie limitów w tej samej wiadomości, w której prosisz o funkcję. W planie Pro opublikowana usługa może działać na do trzech maszynach przy dużym ruchu (zobacz Limity hostingu), więc poproś o liczniki przechowywane w bazie danych, a nie w pamięci jednego serwera.

Powiązane lektury: czym jest API, jak korzystać z API LLM oraz lista kontrolna bezpieczeństwa dla aplikacji zbudowanych z AI.

Pytania