Kako implementirate ograničenje brzine zahtjeva s Redisom?

Question

Accepted Answer

**Ograničenje brzine zahtjeva** (ograničavanje broja dozvoljenih zahtjeva/akcija u vremenskom prozoru) je čest slučaj korištenja Redisa — brzi atomski brojači i TTL-ovi Redisa čine ga idealnim. Postoji nekoliko algoritama (fiksni prozor, klizeći prozor, token bucket), svaki sa svojim kompromisima.

## Fiksni prozor (najjednostavnije)

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

Pristup sa **fiksnim prozorom**: atomski brojač po (korisnik, vremenski-prozor) sa TTL-om — povećaj pri svakom zahtjevu, odbij kada je granica prekoračena. Jednostavan i učinkovit, koristeći atomski `INCR` i automatsko istjecanje.

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

## Klizeći prozor (glađe)

```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 (dopušta kontrolirane rafale)

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

## Zašto je Redis idealan za ovo

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

## Zašto je to važno

Implementacija ograničenja brzine zahtjeva s Redisom je čest, praktičan slučaj korištenja, pa je razumijevanje toga vrijedna znanja — ograničenje brzine zahtjeva (zaštita API-ja i usluga od zlouporabe, osiguravanje poštenog korištenja, sprječavanje preopterećenja) je gotovo univerzalna potreba, a Redis je standardni alat za to.

Razumijevanje **zašto je Redis idealan** je ključno: njegovi **atomski brojači** (`INCR`) čine brojanje brzine ispravnim pod konkurencijom (bez race condition-a/izgubljenih brojanja), njegova **brzina** (u memoriji) dodaje minimalnu kašnjenje svakom zahtjevu, **TTL-ovi** automatski čiste prozore, a ključno je što je **dijeljeno između servera** — omogućavajući **distribuirano ograničenje brzine** gdje svi aplikacijski serveri provode jedno konzistentno ograničenje (neophodno u implementacijama s više servera, gdje po-server limite u memoriji ne bi funkcionirali).

Razumijevanje **algoritama** i njihovih kompromisa omogućuje vam odabir odgovarajućeg: **fiksni prozor** (najjednostavnije — atomski brojač po vremenskom prozoru sa TTL-om, ali dopuštajući rafale na granicama), **klizeći prozor** (glađe i točnije koristeći sortiran skup zahtjeva sa vremenskim žigovima, sa većim troskom memorije), i **token bucket** (dopuštajući kontrolirane rafale pri ograničavanju prosječne brzine, često putem Lua skripte za atomskost).

Znanje kako implementirati ove pristupe (posebno jednostavni, česti uzorak fiksnog prozora sa `INCR` + `EXPIRE`) je praktična, primjenjiva vještina.

Budući da je ograničenje brzine zahtjeva česta potreba za zaštitu usluga, a budući da je Redis (sa svojim atomskim brojaćima, brzinom, TTL-ovima i dijeljenjem između servera) standardni, idealni alat za distribuirano ograničenje brzine zahtjeva, razumijevanje kako ga implementirati s Redisom — algoritama, njihovih kompromisa, i zašto Redis odgovara — je vrijedna, često primjenjiva znanja za izgradnju robusnih, zaštićenih usluga, jedne od najčešćih praktičnih aplikacija Redisa izvan cache-iranja.