AX/GLOSSARY
InżynieriaZaktualizowano: 15 kwi 2026

Rate limiting

Ograniczanie liczby requestów per czas — chroni API przed abuse i overload. Token bucket, leaky bucket, fixed window. Krytyczne dla integracji z external APIs.

Rate limiting to ograniczanie liczby requestów per okres czasu — fundamentalna technika ochrony API przed abuse, overload i unfair usage. Każde poważne API ma rate limity.

Główne algorytmy:

  • Token bucket — ma bucket z N tokenami, każdy request kosztuje 1, bucket refilluje się R/sec. Pozwala bursts, smooth long-term rate.
  • Leaky bucket — requests wchodzą do bucket, "wyciekają" stałą rate. Smooth output, drop overflow.
  • Fixed window — licznik per minutę/godzinę, reset na początku okna. Prosty ale ma "burst at boundary" problem.
  • Sliding window — rolling window, najdokładniejszy ale droższy obliczeniowo.

Typowe limity (2026):

  • Stripe API: 100 req/sec (live mode)
  • OpenAI API: 500-10,000 req/min zależnie od tier
  • Slack API: 1 req/sec per method (Tier 1)
  • LinkedIn: 500 actions/dzień (bardzo restrykcyjne)

Headers do rozpoznania: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After. Production integrations powinny respektować te headers, nie polegać na hardcoded limits.

Co robić gdy hit limit: exponential backoff retry, NIE retry natychmiast — to eskaluje problem. Dla bulk operations: spread requests evenly, plan around limits, użyj batch endpoints jeśli dostępne.