તમે Redis સાથે rate limiting કેવી રીતે લાગુ કરો છો?

Question

Accepted Answer

**Rate limiting** (સમય વિન્ડોમાં કેટલી વિનંતીઓ/ક્રિયાઓ અનુમતિ છે તેને પ્રતિબંધિત કરવું) એક સામાન્ય Redis વપરાશનો કેસ છે — Redis ના ઝડપી atomic counters અને TTLs તેને આદર્શ બનાવે છે. ઘણા અલ્ગોરિધમ્સ અસ્તિત્વમાં છે (fixed window, sliding window, token bucket), પ્રત્યેકમાં trade-offs છે.

## 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** અભિગમ: (user, time-window) દીઠ atomic counter જેમાં TTL છે — પ્રતિ વિનંતીમાં વધારો કરો, મર્યાદા વધી ગયા હોય તો નકારી કાઢો. સરળ અને કાર્યક્ષમ, atomic `INCR` અને auto-expiry ને લાભમાં લે છે.

```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 લાગુ કરવું એક સામાન્ય, વ્યવહારિક વપરાશનો કેસ છે, તેથી તેને સમજવું મૂલ્યવાન જ્ઞાન છે — rate limiting (APIs અને સેવાઓને દુરુપયોગથી બચાવવું, ન્યાયસંગત ઉપયોગ સુનિશ્ચિત કરવું, ઓવરલોડ અટકાવવું) એક લગભગ સર્વશક્તિમાન જરૂરિયાત છે, અને Redis તેનું માનક સાધન છે.

**શા માટે Redis આદર્શ છે** તે સમજવું મુખ્ય છે: તના **atomic counters** (`INCR`) concurrency હેઠળ rate counting સાચું બનાવે છે (કોઈ race conditions/lost counts નહીં), તની **ગતિ** (in-memory) પ્રતિ વિનંતીમાં ન્યૂનતમ latency ઉમેરે છે, **TTLs** window cleanup સ્વચાલિતપણે હેન્ડલ કરે છે, અને નિર્ણાયક રીતે તે **સર્વર્સ જુદે છે** — એક સુસંગત મર્યાદા **વિતરિત rate limiting** સક્ષમ બનાવે છે જ્યાં તમામ application servers એક જ મર્યાદા લાગુ કરે છે (બહુ-સર્વર deployments માં આવશ્યક છે, જ્યાં per-server in-memory મર્યાદાઓ કામ નહીં કરે).

**અલ્ગોરિધમ્સ** અને તેમના trade-offs સમજવું તમને યોગ્ય રીતે પસંદ કરવા દે છે: **fixed window** (સૌથી સરળ — TTL સાથે સમય-વિન્ડો દીઠ atomic counter, પણ boundary bursts ને અનુમતિ આપે છે), **sliding window** (timestamped વિનંતીઓના sorted set નો ઉપયોગ કરીને વધુ સરળ અને વધુ સચોટ, વધુ memory cost સાથે), અને **token bucket** (નિયંત્રિત bursts ને અનુમતિ આપતા સમય સરેરાશ rate ને મર્યાદિત કરે છે, ઘણીવાર atomicity માટે Lua script દ્વારા).

જાણવું કે કેવી રીતે આ લાગુ કરવું (ખાસ કરીને સરળ, સામાન્ય fixed-window pattern with `INCR` + `EXPIRE`) વ્યવહારિક, લાગુ કરી શકાય તેવું કૌશલ્ય છે.

ચાલુ કરવાને rate limiting એક સામાન્ય જરૂરિયાત છે સેવાઓ રક્ષણ માટે, અને Redis (તના atomic counters, ગતિ, TTLs, અને cross-server sharing સાથે) વિતરિત rate limiting માટે માનક, આદર્શ સાધન છે, તેથી Redis સાથે તે કેવી રીતે લાગુ કરવું તે સમજવું — અલ્ગોરિધમ્સ, તેમના trade-offs, અને શા માટે Redis એટલો સુંદર રીતે બંધબેસે છે — મજબૂત, સુરક્ષિત સેવાઓ બનાવવા માટે મૂલ્યવાન, વારંવાર-લાગુ કરી શકાય તેવું જ્ઞાન છે, caching વિગતમાં સૌથી સામાન્ય વ્યવહારિક Redis applications માંથી એક છે.