Hvordan designer du rate limiting?

Question

Accepted Answer

**Rate limiting** begrenser hvor mange forespørsler en klient kan gjøre i en tidsvindu — det beskytter systemer mot misbruk, overbelastning, og sikrer rettferdig bruk. Det er en vanlig system-design-komponent, med flere algoritmer og hensyn.

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

## Implementeringshensyn

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

Å forstå hvordan du designer rate limiting er verdifullt fordi det er en **vanlig system-design-komponent** for å beskytte systemer og sikre rettferdig bruk, så det er viktig praktisk kunnskap.

Rate limiting — begrensning av hvor mange forespørsler en klient kan gjøre i en tidsvindu — adresserer viktige behov: **beskyttelse mot misbruk** (forebygging av angrep som brute force, web scraping, og DoS), **forebygging av overbelastning** (beskyttelse av systemstabilitet), sikring av **rettferdig bruk** (ingen klient monopoliserer ressurser, støtte for lagdelte grenser som gratis vs betalt), og kostnadskontroll.

Disse gjør rate limiting til et vanlig krav for API-er og tjenester.

Å forstå **algoritmene** og deres avveininger — **fast vindu** (enkelt men tillater grensekast), **glidende vindu** (glattere og mer nøyaktig), **token bucket** (tillater kontrollerte kast mens gjennomsnittshastigheten begrenses — populær og fleksibel), og leaky bucket (utjevning av utdata) — er nøkkeldesignkunnskap, fordi valg av riktig algoritme påvirker oppførselen.

Å forstå **implementeringshensyn** er spesielt viktig: håndtering av **distribuert rate limiting** (grenser delt på flere servere, bruker vanligvis **Redis** for raske atomiske tellere delt på instanser — siden per-server-grenser ikke fungerer i distribuerte systemer), identifikasjon av klienter (etter API-nøkkel, bruker, eller IP), tilbakemelding av klare svar (HTTP 429 med retry-after-headere), valg av hvor det skal brukes (gateway, load balancer, eller applikasjon), og granularitet (per bruker, per endepunkt, lagdelt).

Disse gjenspeiler design av rate limiting som fungerer i virkelige distribuerte systemer.

Rate limiting er en hyppig nødvendig komponent, som ofte dukker opp i system design-diskusjoner og intervjuer.

Ettersom rate limiting er en vanlig, viktig komponent for beskyttelse av systemer (mot misbruk og overbelastning) og sikring av rettferdig bruk, og siden forståelse av algoritmene, deres avveininger, og spesielt distribuert implementering (delte grenser via Redis) er viktig for godt design, er forståelse av hvordan du designer rate limiting verdifull, praktisk relevant system-design-kunnskap — en vanlig komponent for beskyttelse av tjenester og sikring av rettferdig bruk, som krever forståelse av algoritmene og distribuert implementering, og et hyppig diskutert emne i system design for bygging av robuste, beskyttede systemer.