Jak byste navrhli rate limiting?

Question

Accepted Answer

**Rate limiting** omezuje počet požadavků, které může klient zaslat v určitém časovém okně — chrání systémy před zneužitím, přetížením a zajišťuje spravedlivé použití. Je to běžná komponenta návrhu systému s několika algoritmy a úvahami.

## Proč rate limiting

```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.
```

## Algoritmy 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)
```

## Úvahy při implementaci

```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
```

## Proč na tom záleží

Porozumění tomu, jak navrhovat rate limiting, je cenné, protože jde o **běžnou komponentu návrhu systému** pro ochranu systémů a zajištění spravedlivého použití, takže jde o důležité praktické znalosti.

Rate limiting — omezení počtu požadavků, které může klient zaslat v určitém časovém okně — řeší důležité potřeby: **ochrana před zneužitím** (prevence útoků jako brute force, scraping a DoS), **prevence přetížení** (ochrana stability systému), zajištění **spravedlivého použití** (aby žádný klient nemonopolizoval prostředky, podpora vrstvených limitů jako free vs paid) a kontrola nákladů.

To dělá rate limiting běžným požadavkem pro API a služby.

Porozumění **algoritmům** a jejich kompromisům — **fixed window** (jednoduchý, ale umožňující nárazy na hranicích), **sliding window** (hladší a přesnější), **token bucket** (umožňující kontrolované nárazy při omezení průměrné rychlosti — populární a flexibilní) a leaky bucket (vyhlazování výstupu) — je klíčová znalost při návrhu, protože volba správného algoritmu ovlivňuje chování.

Porozumění **úvahám při implementaci** je zvláště důležité: řešení **distribuovaného rate limitingu** (limity sdílené mezi více servery, běžně používající **Redis** pro rychlé atomické čítače sdílené mezi instancemi — protože limity na jeden server nefungují v distribuovaných systémech), identifikace klientů (podle API klíče, uživatele nebo IP), vrácení jasných odpovědí (HTTP 429 s hlavičkami retry-after), volba místa aplikace (gateway, load balancer nebo aplikace) a granularita (na uživatele, na endpoint, vrstvené).

To odráží návrh rate limitingu, který funguje v reálných distribuovaných systémech.

Rate limiting je často potřebná komponenta, která se často objevuje v diskusích o návrhu systému a pohovorech.

Protože je rate limiting běžnou, důležitou komponentou pro ochranu systémů (před zneužitím a přetížením) a zajištění spravedlivého použití, a protože porozumění algoritmům, jejich kompromisům a zejména distribuované implementaci (sdílené limity přes Redis) je důležité pro jeho dobrý návrh, je porozumění návrhu rate limitingu cenné, prakticky relevantní znalosti o návrhu systému — běžná komponenta pro ochranu služeb a zajištění spravedlivého použití, vyžadující porozumění algoritmům a distribuované implementaci, a často diskutované téma v návrhu systému pro budování robustních, chráněných systémů.