Kako dizajnirate ograničenje brzine zahtjeva?

Question

Accepted Answer

**Ograničenje brzine zahtjeva** ograničava koliko zahtjeva klijent može napraviti u vremenskom prozoru — štiteći sustave od zlouporabe, preopterećenja i osiguravajući poštenu upotrebu. To je česta komponenta u dizajnu sustava, s nekoliko algoritama i razmatranja.

## Zašto je ograničenje brzine zahtjeva važno

```text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
```

## Algoritmi ograničenja brzine zahtjeva

```text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
  ✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
  the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)
```

## Razmatranja pri implementaciji

```text
✓ DISTRIBUTED → limits must be shared across servers → use a centralized store (REDIS is
  common: atomic counters, fast, shared across instances)
✓ Identify the client → by API key, user ID, IP
✓ Return clear responses → HTTP 429 (Too Many Requests); include limit/retry-after headers
✓ Where → at the API gateway, load balancer, or application layer
✓ Granularity → per user, per endpoint, global; different tiers/limits
```

## Zašto je to važno

Razumijevanje kako dizajnirati ograničenje brzine zahtjeva je vrijedno jer je to **česta komponenta u dizajnu sustava** za zaštitu sustava i osiguravanje poštene upotrebe, pa je to važno praktično znanje.

Ograničenje brzine zahtjeva — ograničavanje koliko zahtjeva klijent može napraviti u vremenskom prozoru — rješava važne potrebe: **zaštita od zlouporabe** (sprječavanje napada poput brute force, web scrapinga i DoS), **sprječavanje preopterećenja** (zaštita stabilnosti sustava), osiguravanje **poštene upotrebe** (niti jedan klijent ne monopolizira resurse, podrška slojevitim limitima kao što su besplatni ili plaćeni) i kontrola troškova.

To čini ograničenje brzine zahtjeva čestom potrebom za API-je i usluge.

Razumijevanje **algoritama** i njihovih kompromisa — **fiksni prozor** (jednostavan ali omogućavajući burste na granicama), **klizajući prozor** (glađe i preciznije), **token bucket** (omogućavajući kontrolirane burste dok se ograničava prosječna brzina — popularno i fleksibilno) i leaky bucket (glađenje izlaza) — ključno je znanje o dizajnu, jer izbor pravog algoritma utječe na ponašanje.

Razumijevanje **razmatranja pri implementaciji** je posebno važno: rukovanje **distribuiranim ograničenjem brzine zahtjeva** (limitima podijeljenim preko više poslužitelja, često koristeći **Redis** za brze atomske brojače podijeljene između instanci — jer limitima po poslužitelju ne funkcioniraju u distribuiranim sustavima), identificiranje klijenta (prema API ključu, korisniku ili IP adresi), vraćanje jasnih odgovora (HTTP 429 s retry-after zaglavljem), izbor gdje ga primijeniti (gateway, load balancer ili aplikacija) i granularnost (po korisniku, po endpointu, slojevito).

Ovi elementi odražavaju dizajniranje ograničenja brzine zahtjeva koje funkcionira u stvarnim distribuiranim sustavima.

Ograničenje brzine zahtjeva je često potrebna komponenta koja se često pojavljuje u raspravama o dizajnu sustava i razgovorima za posao.

Budući da je ograničenje brzine zahtjeva česta, važna komponenta za zaštitu sustava (od zlouporabe i preopterećenja) i osiguravanje poštene upotrebe, i budući da je razumijevanje algoritama, njihovih kompromisa i posebno distribuirane implementacije (dijeljenih limitima preko Redis-a) važno za dobar dizajn, razumijevanje kako dizajnirati ograničenje brzine zahtjeva je vrijednost, praktično relevantno znanje o dizajnu sustava — česta komponenta za zaštitu usluga i osiguravanje poštene upotrebe, zahtijevajući razumijevanje algoritama i distribuirane implementacije, i često raspravljena tema u dizajnu sustava za izgradnju robustan, zaštićenih sustava.