Hvordan designer du rate limiting?

Question

Accepted Answer

**Rate limiting** begrænser, hvor mange requests en klient kan lave inden for et tidsvindue — det beskytter systemer mod misbrug, overbelastning og sikrer fair brug. Det er en almindelig system-design-komponent med flere algoritmer og overvejelser.

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

## Rate limiting-algoritmer

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

## Implementeringsovervejelser

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

## Hvorfor det betyder noget

At forstå, hvordan man designer rate limiting, er værdifuldt, fordi det er en **almindelig system-design-komponent** til at beskytte systemer og sikre fair brug, så det er vigtig praktisk viden.

Rate limiting — at begrænse, hvor mange requests en klient kan lave inden for et tidsvindue — adresserer vigtige behov: **beskyttelse mod misbrug** (forhindring af angreb som brute force, scraping og DoS), **forhindring af overbelastning** (beskyttelse af systemstabilitet), sikring af **fair brug** (ingen klient monopoliserer ressourcer, støtte til tiered limits som gratis vs. betalt), og omkostningskontrol.

Dette gør rate limiting til et almindeligt krav for APIs og services.

At forstå **algoritmerne** og deres trade-offs — **fixed window** (simpel men tillader grænsebursts), **sliding window** (glattere og mere nøjagtig), **token bucket** (tillader kontrollerede bursts samtidig med at begrænse gennemsnitshastighed — populær og fleksibel), og leaky bucket (glatning af output) — er vigtig designviden, da valg af den rigtige algoritme påvirker adfærd.

At forstå **implementeringsovervejelserne** er særligt vigtig: håndtering af **distribueret rate limiting** (limits delt på tværs af flere servere, almindeligvis brugende **Redis** til hurtige atomare tællere delt på tværs af instanser — da per-server limits ikke fungerer i distribuerede systemer), identifikation af klienter (ved API-nøgle, bruger eller IP), retur af klare svar (HTTP 429 med retry-after headers), valg af hvor det skal anvendes (gateway, load balancer eller applikation), og granularitet (per bruger, per endpoint, tiered).

Disse afspejler design af rate limiting, der fungerer i rigtige distribuerede systemer.

Rate limiting er en hyppigt påkrævet komponent, der ofte optræder i system design-diskussioner og interviews.

Da rate limiting er en almindelig, vigtig komponent til at beskytte systemer (mod misbrug og overbelastning) og sikre fair brug, og da det at forstå algoritmerne, deres trade-offs, og især distribueret implementering (delte limits via Redis) er vigtig for at designe det godt, er det at forstå, hvordan man designer rate limiting, værdifuld, praktisk relevant system-design-viden — en almindelig komponent til at beskytte services og sikre fair brug, der kræver forståelse af algoritmerne og distribueret implementering, og et hyppigt diskuteret emne inden for system design til at bygge robuste, beskyttede systemer.