Hoe implementeer je rate limiting met Redis?

Question

Accepted Answer

**Rate limiting** (beperken hoeveel verzoeken/acties in een bepaald tijdsvenster zijn toegestaan) is een veelgebruikt Redis use case — Redis's snelle atomaire tellers en TTLs maken het ideaal. Er bestaan verschillende algoritmen (vast venster, schuivend venster, token bucket), elk met voor- en nadelen.

## Vast venster (eenvoudigst)

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

De **vast venster** benadering: een atomaire teller per (gebruiker, tijdsvenster) met een TTL — verhoog per verzoek, weiger wanneer over de limiet. Eenvoudig en efficiënt, gebruikmakend van atomaire `INCR` en automatische verval.

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

## Schuivend venster (soepeler)

```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 (staat gecontroleerde pieken toe)

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

## Waarom Redis ideaal is voor dit

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

## Waarom het belangrijk is

Rate limiting implementeren met Redis is een veelgebruikt, praktisch use case, dus het begrijpen ervan is waardevolle kennis — rate limiting (APIs en services beschermen tegen misbruik, eerlijk gebruik garanderen, overbelasting voorkomen) is bijna universeel nodig, en Redis is het standaardgereedschap ervoor.
\
het **waarom Redis ideaal is** begrijpen is essentieel: zijn **atomaire tellers** (`INCR`) maken rate counting correct onder gelijktijdigheid (geen race conditions/verloren tellingen), zijn **snelheid** (in-memory) voegt minimale latentie aan elk verzoek toe, **TTLs** behandelen vensterreiniging automatisch, en cruciaal is het **gedeeld over servers** — waardoor **gedistribueerde rate limiting** mogelijk is waarbij alle toepassingsservers één consistente limiet handhaven (essentieel in implementaties met meerdere servers, waar per-server in-memory limieten niet zouden werken).

het **algoritmen** en hun voor- en nadelen begrijpen stelt je in staat om passend te kiezen: **vast venster** (eenvoudigst — een atomaire teller per tijdsvenster met een TTL, maar pieken op grenzen toegestaan), **schuivend venster** (soepeler en nauwkeuriger met een gesorteerde set van getimede verzoeken, tegen hogere geheugenkosten), en **token bucket** (gecontroleerde pieken toestaan terwijl het gemiddelde tempo wordt beperkt, vaak via een Lua-script voor atomiciteit).

Weten hoe je deze implementeert (vooral het eenvoudige, veelgebruikte vast-venster-patroon met `INCR` + `EXPIRE`) is praktische, toepasbare vaardigheid.

Omdat rate limiting een veelgebruikte vereiste is voor servicebescherming, en omdat Redis (met zijn atomaire tellers, snelheid, TTLs en sharing over servers) het standaard, ideale gereedschap voor gedistribueerde rate limiting is, het begrijpen hoe je het met Redis implementeert — de algoritmen, hun voor- en nadelen, en waarom Redis zo goed past — is waardevolle, vaak toepasselijke kennis voor het bouwen van robuuste, beschermde services, één van de meest voorkomende praktische Redis-toepassingen buiten caching.