Rate limiting (limitowanie zapytań)

Definicja

Rate limiting to ograniczanie liczby zapytań do systemu w danym czasie (np. 60/min), żeby chronić usługę przed przeciążeniem i nadużyciami.

Co to w zasadzie jest?

To „bramka”, która mówi: „OK, możesz pytać, ale nie 1000 razy na minutę”. W AI ma to znaczenie, bo:

• modele i narzędzia kosztują,
• ataki i błędy potrafią generować lawinę żądań,
• pętle agentów mogą zrobić „samozapętlenie”.

Praktyczne zastosowania (konkretne scenariusze)

Scenariusz 1: Chatbot

• Cel: limit per użytkownik, żeby uniknąć spamu.
• Wejście: ruch użytkowników i limity systemu.
• Kroki: policz żądania -> zastosuj limit -> zwróć komunikat.
• Rezultat: stabilniejsze działanie usługi.
• Zabezpieczenie: czytelne limity i obsługa wyjątków.

Scenariusz 2: API

• Cel: limit per klucz, żeby kontrolować koszty i stabilność.
• Wejście: ruch użytkowników i limity systemu.
• Kroki: policz żądania -> zastosuj limit -> zwróć komunikat.
• Rezultat: stabilniejsze działanie usługi.
• Zabezpieczenie: czytelne limity i obsługa wyjątków.

Scenariusz 3: Agent

• Cel: limit kroków narzędzi (max 20 wywołań).
• Wejście: ruch użytkowników i limity systemu.
• Kroki: policz żądania -> zastosuj limit -> zwróć komunikat.
• Rezultat: stabilniejsze działanie usługi.
• Zabezpieczenie: czytelne limity i obsługa wyjątków.

Ryzyka i jak je ograniczać

Ryzyko 1: Blokowanie „dobrych” użytkowników

• Ryzyko: blokowanie „dobrych” użytkowników.
• Jak ograniczać: różne limity dla różnych ról + jasny komunikat „spróbuj później”.

Ryzyko 2: Obchodzenie limitów

• Ryzyko: obchodzenie limitów.
• Jak ograniczać: identyfikacja po kluczu + IP + zachowaniu, analiza nadużyć.

Ryzyko 3: Brak widoczności, kiedy limit działa

• Ryzyko: brak widoczności, kiedy limit działa.
• Jak ograniczać: monitoring i alerty + logi.

Mapa powiązań

• API → rate limiting jest częścią API.
• SSO/IAM → limity często zależą od roli/użytkownika.
• LLMOps / Monitoring jakości → obserwacja stabilności.
• Agentic workflow → limity chronią przed pętlami.
• Mini-przepływ: Żądanie → limit? → OK / odrzuć z informacją

Diagram

flowchart LR
    A[Żądanie]
    B[Sprawdź limit]
    C[Przepuść]
    D[Odrzuć lub poczekaj]
    E[Log]
    A --> B
    B --> C
    B --> D
    C --> E
    D --> E

Diagram pokazuje, że system ogranicza liczbę zapytań w czasie, aby chronić stabilność i koszty.