Hur implementerar du rate limiting med Redis?

Question

Accepted Answer

**Rate limiting** (begränsa hur många förfrågningar/åtgärder som tillåts inom ett tidsinterval) är ett vanligt Redis-användningsfall — Redis snabba atomära räknare och TTL:er gör det idealt. Det finns flera algoritmer (fixed window, sliding window, token bucket), var och en med sina avvägningar.

## Fixed window (enklast)

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

**Fixed window**-metoden: en atomär räknare per (användare, tidsinterval) med en TTL — öka per förfrågan, avvisa när gränsen överskrids. Enkel och effektiv, med atomär `INCR` och automatisk utgång.

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

## Sliding window (smidigare)

```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 (tillåter kontrollerade burst)

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

## Varför Redis är idealt för detta

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

## Varför det är viktigt

Att implementera rate limiting med Redis är ett vanligt, praktiskt användningsfall, så att förstå det är värdefull kunskap — rate limiting (skydda API:er och tjänster från missbruk, säkerställa rättvis användning, förhindra överbelastning) är ett nästan universellt behov, och Redis är standardverktyget för det.

Att förstå **varför Redis är idealt** är nyckeln: dess **atomära räknare** (`INCR`) gör räkning korrekt under samtidighet (ingen race conditions/förlorade räknor), dess **hastighet** (i minnet) lägger till minimal latens för varje förfrågan, **TTL:er** hanterar fönsterrensning automatiskt, och viktigt är det **delat över servrar** — vilket möjliggör **distribuerad rate limiting** där alla applikationsservrar hanterar en konsekvent gräns (väsentligt i distributioner med flera servrar, där per-server minnesbegränsningar inte fungerar).

Att förstå **algoritmerna** och deras avvägningar låter dig välja lämpligt: **fixed window** (enklast — en atomär räknare per tidsinterval med en TTL, men tillåter burst vid gränser), **sliding window** (smidigare och mer exakt med en sorterad uppsättning tidsstämplade förfrågningar, till högre minneskostnad), och **token bucket** (tillåter kontrollerade burst medan man begränsar genomsnittshastigheten, ofta via ett Lua-skript för atomaritet).

Att veta hur man implementerar dessa (särskilt det enkla, vanliga fixed-window-mönstret med `INCR` + `EXPIRE`) är praktisk, tillämplig kunskap.

Eftersom rate limiting är ett vanligt krav för att skydda tjänster, och eftersom Redis (med sina atomära räknare, hastighet, TTL:er och delning över servrar) är standardverktyget för distribuerad rate limiting, är förståelse för hur man implementerar det med Redis — algoritmerna, deras avvägningar och varför Redis passar så väl — värdefull, ofta tillämpbar kunskap för att bygga robusta, skyddade tjänster, ett av de vanligaste praktiska Redis-användningsfallen bortom caching.