Hur designar du rate limiting?

Question

Accepted Answer

**Rate limiting** begränsar hur många förfrågningar en klient kan göra inom ett tidsfönster — det skyddar system från missbruk, överbelastning och säkerställer rättvis användning. Det är en vanlig system-design-komponent med flera algoritmer och överväganden.

## Varför rate limiting är viktigt

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

## Implementeringsöverväganden

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

## Varför det spelar roll

Att förstå hur man designar rate limiting är värdefullt eftersom det är en **vanlig system-design-komponent** för att skydda system och säkerställa rättvis användning, så det är viktig praktisk kunskap.

Rate limiting — att begränsa hur många förfrågningar en klient kan göra inom ett tidsfönster — adresserar viktiga behov: **skydd mot missbruk** (förebyggande av attacker som brute force, skrapning och DoS), **förebyggande av överbelastning** (skydd av systemstabilitet), säkerställande av **rättvis användning** (ingen klient monopoliserar resurser, stöd för nivåbaserade gränser som gratis kontra betald), och kostnadskontroll.

Dessa gör rate limiting till ett vanligt krav för API:er och tjänster.

Att förstå **algoritmerna** och deras avvägningar — **fast fönster** (enkelt men tillåter gränsbursningar), **glidande fönster** (mjukare och mer korrekt), **token bucket** (tillåter kontrollerade bursningar samtidigt som det begränsar genomsnittshastighet — populär och flexibel), och läckande bucket (utjämnande av utgång) — är kunskapen om nyckeldesign, eftersom val av rätt algoritm påverkar beteendet.

Att förstå **implementeringsöverväganden** är särskilt viktigt: hantering av **distribuerad rate limiting** (gränser delas mellan flera servrar, vanligtvis med **Redis** för snabba atomära räknare delt mellan instanser — eftersom gränser per server inte fungerar i distribuerade system), identifiering av klienter (via API-nyckel, användare eller IP), returnering av tydliga svar (HTTP 429 med retry-after-headers), val av var det ska tillämpas (gateway, lastbalanserare eller applikation), och granularitet (per användare, per endpoint, nivåbaserat).

Dessa återspeglar designen av rate limiting som fungerar i riktiga distribuerade system.

Rate limiting är en frekvent behövd komponent som ofta dyker upp i system design-diskussioner och intervjuer.

Eftersom rate limiting är en vanlig, viktig komponent för att skydda system (från missbruk och överbelastning) och säkerställa rättvis användning, och eftersom förståelse för algoritmerna, deras avvägningar och särskilt distribuerad implementering (delade gränser via Redis) är viktig för att designa det väl, är förståelse för hur man designar rate limiting värdefulld, praktiskt relevant system-design-kunskap — en vanlig komponent för att skydda tjänster och säkerställa rättvis användning, som kräver förståelse för algoritmerna och distribuerad implementering, och ett ofta diskuterat ämne inom system design för att bygga robusta, skyddade system.