Jak zaprojektujesz rate limiting?

Question

Accepted Answer

**Rate limiting** ogranicza liczbę żądań, które klient może wysłać w oknie czasowym — chroniąc systemy przed nadużyciami, przeciążeniem i zapewniając uczciwe użytkowanie. To typowy komponent projektowania systemów z kilkoma algorytmami i rozważaniami.

## Dlaczego to ważne

```text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
```

## Algorytmy rate limitingu

```text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
  ✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
  the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)
```

## Rozważania implementacyjne

```text
✓ DISTRIBUTED → limits must be shared across servers → use a centralized store (REDIS is
  common: atomic counters, fast, shared across instances)
✓ Identify the client → by API key, user ID, IP
✓ Return clear responses → HTTP 429 (Too Many Requests); include limit/retry-after headers
✓ Where → at the API gateway, load balancer, or application layer
✓ Granularity → per user, per endpoint, global; different tiers/limits
```

## Dlaczego to ważne

Zrozumienie, jak zaprojektujesz rate limiting, jest wartościowe, ponieważ to **typowy komponent projektowania systemów** do ochrony systemów i zapewnienia uczciwego użytkowania, dlatego jest to ważna praktyczna wiedza.

Rate limiting — ograniczenie liczby żądań, które klient może wysłać w oknie czasowym — odpowiada ważnym potrzebom: **ochrona przed nadużyciami** (zapobieganie atakom takim jak brute force, scraping i DoS), **zapobieganie przeciążeniu** (ochrona stabilności systemu), zapewnienie **uczciwego użytkowania** (żaden klient nie monopolizuje zasobów, wspieranie limitów warstwowych takich jak darmowy vs płatny) i kontrola kosztów.

To czyni rate limiting powszechnym wymaganiem dla API i usług.

Zrozumienie **algorytmów** i ich kompromisów — **fixed window** (proste, ale pozwalające na rajdy graniczne), **sliding window** (gładsze i dokładniejsze), **token bucket** (pozwalające na kontrolowane rajdy przy jednoczesnym ograniczeniu średniej szybkości — popularne i elastyczne) oraz leaky bucket (wygładzające wyjście) — to kluczowa wiedza projektowa, ponieważ wybór odpowiedniego algorytmu wpływa na zachowanie.

Zrozumienie **rozważań implementacyjnych** jest szczególnie ważne: obsługa **rozproszonego rate limitingu** (limity współdzielone między wieloma serwerami, powszechnie używające **Redis** do szybkich liczników atomowych współdzielonych między instancjami — ponieważ limity dla każdego serwera nie działają w systemach rozproszonych), identyfikacja klientów (po kluczu API, użytkowniku lub IP), zwracanie jasnych odpowiedzi (HTTP 429 z nagłówkami retry-after), wybór miejsca jego zastosowania (gateway, load balancer lub aplikacja) i granularność (per użytkownik, per endpoint, warstwowy).

To odzwierciedla projektowanie rate limitingu, który działa w rzeczywistych systemach rozproszonych.

Rate limiting to często potrzebny komponent, často pojawiający się w dyskusjach i wywiadach dotyczących projektowania systemów.

Ponieważ rate limiting to typowy, ważny komponent do ochrony systemów (przed nadużyciami i przeciążeniem) i zapewnienia uczciwego użytkowania, a ponieważ zrozumienie algorytmów, ich kompromisów, a szczególnie rozproszonej implementacji (współdzielone limity przez Redis) jest ważne dla jego dobrego projektowania, zrozumienie jak zaprojektujesz rate limiting to cenna, praktycznie istotna wiedza o projektowaniu systemów — typowy komponent do ochrony usług i zapewnienia uczciwego użytkowania, wymagający zrozumienia algorytmów i rozproszonej implementacji, i często omawiany temat w projektowaniu systemów do budowania solidnych, chronionych systemów.