Bagaimana Anda mengimplementasikan rate limiting dengan Redis?

Question

Accepted Answer

**Rate limiting** (membatasi berapa banyak permintaan/tindakan yang diizinkan dalam jendela waktu) adalah kasus penggunaan Redis yang umum — penghitung atomic dan TTL Redis yang cepat membuatnya ideal. Beberapa algoritma ada (fixed window, sliding window, token bucket), masing-masing dengan trade-off.

## Fixed window (paling sederhana)

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

Pendekatan **fixed window**: penghitung atomic per (user, time-window) dengan TTL — increment per permintaan, tolak ketika melebihi batas. Sederhana dan efisien, memanfaatkan atomic `INCR` dan auto-expiry.

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

## Sliding window (lebih halus)

```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 (memungkinkan burst terkontrol)

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

## Mengapa Redis ideal untuk ini

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

## Mengapa ini penting

Mengimplementasikan rate limiting dengan Redis adalah kasus penggunaan yang umum dan praktis, jadi memahaminya adalah pengetahuan yang berharga — rate limiting (melindungi API dan layanan dari penyalahgunaan, memastikan penggunaan yang adil, mencegah kelebihan beban) adalah kebutuhan yang hampir universal, dan Redis adalah alat standar untuk itu.

Memahami **mengapa Redis ideal** adalah kunci: **penghitung atomic** (`INCR`) membuatnya benar dalam menghitung rate di bawah konkurensi (tanpa race conditions/lost counts), **kecepatan** (in-memory) menambah minimal latency ke setiap permintaan, **TTL** menangani pembersihan window secara otomatis, dan yang sangat penting **shared across servers** — memungkinkan **distributed rate limiting** di mana semua application server menerapkan satu batas yang konsisten (essential dalam multi-server deployments, di mana per-server in-memory limits tidak akan bekerja).

Memahami **algoritma** dan trade-off mereka memungkinkan Anda memilih secara tepat: **fixed window** (paling sederhana — penghitung atomic per time-window dengan TTL, tetapi memungkinkan burst boundary), **sliding window** (lebih halus dan akurat menggunakan sorted set dari timestamped requests, dengan biaya memory yang lebih tinggi), dan **token bucket** (memungkinkan burst terkontrol sambil membatasi rata-rata rate, sering melalui Lua script untuk atomicity).

Mengetahui cara mengimplementasikan ini (terutama pola fixed-window yang sederhana dan umum dengan `INCR` + `EXPIRE`) adalah keterampilan praktis yang dapat diterapkan.

Karena rate limiting adalah persyaratan umum untuk melindungi layanan, dan karena Redis (dengan penghitung atomic, kecepatan, TTL, dan sharing lintas-server) adalah alat standar dan ideal untuk distributed rate limiting, memahami cara mengimplementasinya dengan Redis — algoritma, trade-off mereka, dan mengapa Redis sangat cocok — adalah pengetahuan yang berharga dan sering dapat diterapkan untuk membangun layanan yang robust dan terlindungi, salah satu aplikasi Redis praktis paling umum di luar caching.