آپ Redis کے ساتھ rate limiting کو کیسے implement کرتے ہیں؟

Question

Accepted Answer

**Rate limiting** (یعنی کتنی درخواستیں/کارروائیاں ایک وقت کی کھڑکی میں دی جائیں اس پر پابندی) ایک عام Redis استعمال ہے — Redis کے تیز ایٹامک counters اور TTLs اسے بہترین بناتے ہیں۔ کئی الگورتھم موجود ہیں (fixed window، sliding window، token bucket)، ہر ایک میں فوائل و نقصانات ہیں۔

## Fixed window (سب سے سادہ)

```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** طریقہ: (صارف، وقت کی کھڑکی) کے لیے ایک ایٹامک counter جس کی TTL ہو — ہر درخواست پر اضافہ کریں، حد سے اوپر ہو تو مسترد کریں۔ سادہ اور موثر، ایٹامک `INCR` اور خود بخود expire ہونے کا فائدہ اٹھاتے ہوئے۔

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

## Sliding window (زیادہ ہموار)

```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 (کنٹرول شدہ 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
```

## Redis اس کے لیے بہترین کیوں ہے

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

## یہ اہم کیوں ہے

Redis کے ساتھ rate limiting implement کرنا ایک عام، عملی استعمال ہے، تو یہ سمجھنا قیمتی علم ہے — rate limiting (APIs اور سروسز کو غلط استعمال سے بچانا، منصفانہ استعمال یقینی بنانا، اوور لوڈ روکنا) تقریباً ہر جگہ ضروری ہے، اور Redis اس کے لیے معیاری ٹول ہے۔

**Redis بہترین کیوں ہے** یہ سمجھنا اہم ہے: اس کے **ایٹامک counters** (`INCR`) rate گننے کو بیک وقت کی کارروائی میں درست بناتے ہیں (کوئی race conditions/ضائع شدہ گنتی نہیں)، اس کی **رفتار** (in-memory) ہر درخواست میں کم تاخیر شامل کرتی ہے، **TTLs** کھڑکی کی صفائی خود بخود کرتے ہیں، اور اہم بات یہ کہ یہ **سرورز میں شریکی ہے** — **distributed rate limiting** قابل بناتا ہے جہاں تمام application سرورز ایک مستقل حد نافذ کریں (multi-server deployments میں ضروری ہے، جہاں فی سرور in-memory حدیں کام نہیں آتیں)۔

**الگورتھمس** اور ان کے فوائل و نقصانات سمجھنا آپ کو درست انتخاب کرنے دیتا ہے: **fixed window** (سب سے سادہ — ایک TTL کے ساتھ ہر وقتی کھڑکی کے لیے ایک ایٹامک counter، لیکن سرحد پر bursts دیتے ہوئے)، **sliding window** (زیادہ ہموار اور درست timestamps کے sorted set استعمال کرتے ہوئے، زیادہ میموری کی قیمت پر)، اور **token bucket** (کنٹرول شدہ bursts کی اجازت دیتے ہوئے اوسط شرح میں حد کرتے ہوئے، اکثر atomicity کے لیے Lua script کے ذریعے)۔

یہ جاننا کہ یہ کیسے implement کریں (خاص طور پر سادہ، عام fixed-window pattern جو `INCR` + `EXPIRE` کے ساتھ ہو) عملی، قابل اطلاق مہارت ہے۔

چونکہ rate limiting سروسز کے تحفظ کے لیے عام ضرورت ہے، اور Redis (اپنے ایٹامک counters، رفتار، TTLs، اور cross-server sharing کے ساتھ) distributed rate limiting کے لیے معیاری، بہترین ٹول ہے، Redis کے ساتھ یہ implement کرنا سمجھنا — الگورتھمس، ان کے فوائل و نقصانات، اور Redis کیوں موزوں ہے — مضبوط، محفوظ سروسز بنانے کے لیے قیمتی، بار بار استعمال ہونے والا علم ہے، caching سے ماورا Redis کے سب سے عام عملی استعمالات میں سے ایک۔