Hvordan implementerer du rate limiting med Redis?

Question

Accepted Answer

**Rate limiting** (begrænsning af hvor mange anmodninger/handlinger der er tilladt i et tidsvindue) er et almindeligt Redis-use case — Redis's hurtige atomare tællere og TTL'er gør det ideelt. Flere algoritmer findes (fixed window, sliding window, token bucket), hver med deres trade-offs.

## Fixed window (simplest)

```js
// allow N requests per time window using an atomic counter with a TTL
async function rateLimit(userId, limit = 100, windowSec = 60) {
  const key = `rate:${userId}:${Math.floor(Date.now() / 1000 / windowSec)}`;
  const count = await redis.incr(key);     // atomic increment
  if (count === 1) await redis.expire(key, windowSec);  // set TTL on first request
  return count <= limit;                    // allowed if under the limit
}
// → INCR is atomic (correct under concurrency); the key auto-expires each window
```

Den **fixed window**-tilgang: en atomar tæller per (bruger, tidsvindue) med en TTL — inkrementér per anmodning, afvis når over grænsen. Enkel og effektiv, leveraging atomic `INCR` og auto-expiry.

```text
✗ Limitation: bursts at window boundaries (2x limit possible across two adjacent windows)
```

## Sliding window (smoothere)

```text
SLIDING WINDOW → tracks requests over a rolling time period (no boundary bursts)
  → often uses a SORTED SET: add each request with a timestamp score,
    remove old entries (ZREMRANGEBYSCORE), count remaining (ZCARD)
  ✓ More accurate/smooth  ✗ More memory and complexity
```

## Token bucket (tillader kontrollerede bursts)

```text
TOKEN BUCKET → tokens refill at a steady rate; each request consumes a token
  → allows bursts (up to the bucket size) while limiting the average rate
  → often implemented with a Lua SCRIPT for atomic check-and-consume
```

## Hvorfor Redis er ideelt for dette

```text
✓ ATOMIC counters (INCR) → correct under concurrency, no race conditions
✓ Fast (in-memory) → minimal latency added to each request
✓ TTL → automatic window cleanup (no manual expiry management)
✓ SHARED across servers → distributed rate limiting (all app servers use one Redis)
→ Redis is the standard tool for distributed rate limiting.
```

## Hvorfor det betyder noget

Implementering af rate limiting med Redis er et almindeligt, praktisk use case, så forståelse af det er værdifuld viden — rate limiting (beskyttelse af API'er og tjenester mod misbrug, sikring af fair brug, forebyggelse af overbelastning) er et næsten universelt behov, og Redis er standardværktøjet for det.

At forstå **hvorfor Redis er ideelt** er nøglen: dets **atomare tællere** (`INCR`) gør rate counting korrekt under concurrency (ingen race conditions/tabte tællinger), dets **hastighed** (in-memory) tilføjer minimal latens til hver anmodning, **TTL'er** håndterer vinduesnedrivning automatisk, og afgørende er det **delt på tværs af servere** — hvilket muliggør **distribueret rate limiting** hvor alle applikationsservere håndhæver én konsistent grænse (essentiel i multi-server-deployments, hvor per-server in-memory-grænser ikke ville fungere).

At forstå **algoritmerne** og deres trade-offs lader dig vælge passende: **fixed window** (simplest — en atomar tæller per tidsvindue med en TTL, men tillader grænsebursts), **sliding window** (smoothere og mere nøjagtig ved brug af et sorted set af tidsmarkeringsanmodninger, til højere hukommelsesomkostninger), og **token bucket** (tillader kontrollerede bursts samtidig med begrænsning af gennemsnitshastigheden, ofte via et Lua-script for atomaritet).

At vide, hvordan man implementerer disse (især det simple, almindeligt fixed-window-mønster med `INCR` + `EXPIRE`) er praktisk, applicable færdighed.

Fordi rate limiting er et almindeligt krav til beskyttelse af tjenester, og fordi Redis (med dets atomare tællere, hastighed, TTL'er og cross-server-deling) er standardværktøjet, ideelt værktøj til distribueret rate limiting, er forståelse af, hvordan man implementerer det med Redis — algoritmerne, deres trade-offs, og hvorfor Redis passer så godt — værdifuld, hyppigt applicable viden til at bygge robuste, beskyttede tjenester, et af de mest almindelige praktiske Redis-programmer uden for caching.