1) Kazde zadanie jest identyfikowane po kluczu API (i ewentualnie uzytkowniku/planie). 2) Brama sprawdza liczniki uzycia dla tego klucza wzgledem skonfigurowanych limitow (np. RPM, TPM, kwota) uzywajac algorytmu (token bucket / sliding window). 3) Jesli limit nie jest przekroczony — zadanie przechodzi, a liczniki sa aktualizowane (we wspoldzielonym magazynie, np. Redis). 4) Jesli limit jest przekroczony — zadanie jest odrzucane (HTTP 429, czesto z naglowkiem Retry-After) albo opoznione/kolejkowane.
Bez limitow pojedynczy klient moze przeciazyc backend, wyczerpac kwoty dostawcow lub wygenerowac niekontrolowane koszty. Rate limiting per klucz API chroni system, zapewnia sprawiedliwy dostep i utrzymuje koszty pod kontrola.
Przechowuje biezace zuzycie per klucz (zadania/tokeny w oknie), zwykle we wspoldzielonym magazynie (np. Redis) dla spojnosci miedzy instancjami.
Oficjalna
Decyduje, czy zadanie miesci sie w limicie: token bucket, leaky bucket lub okno przesuwne (sliding window).
Oficjalna
Definicja limitow per klucz/plan (RPM/TPM/kwota) oraz miejsce, w ktorym zadanie jest przepuszczane, odrzucane (429) lub opozniane.
Oficjalna
Scisle globalne limity wymagaja spojnego licznika, co dodaje latencje; lokalne liczniki sa szybsze, ale mniej dokladne.
Przy oknie stalym (fixed window) wszyscy klienci moga uderzyc jednoczesnie po resecie, powodujac skok obciazenia.
Brak jasnych naglowkow (limit/pozostalo/Retry-After) utrudnia klientom poprawna obsluge 429.
Złożoność czasowa: O(1) na zadanie. Złożoność przestrzenna: O(liczba aktywnych kluczy).
Utrzymanie dokladnych, spojnych licznikow miedzy wieloma instancjami bramy przy niskiej latencji jest glownym wyzwaniem (kompromis dokladnosc vs wydajnosc).
Co jest limitowane: zadania (RPM/RPD), tokeny (TPM), rownoczesnosc, budzet.
Token bucket, leaky bucket, fixed/sliding window.
Per klucz API, per uzytkownik, per plan/grupa, globalnie.
Wynik zalezy od biezacego zuzycia danego klucza.
Decyzja przepusc/odrzuc na podstawie licznikow, bez routingu.
Sprawdzenia sa niezalezne per zadanie; wyzwaniem jest globalna spojnosc licznikow.
Sprawdzanie limitow to lekka operacja I/O-bound; dziala na dowolnym CPU. Kluczowy jest szybki, wspoldzielony magazyn licznikow (np. Redis).
