Hogyan tervezel sebességkorlátozást?

Question

Accepted Answer

A **sebességkorlátozás** korlátozza, hogy egy kliens hány kérést intézhet egy időablakban — védelmet nyújtva a rendszereket a visszaélések, túlterhelés ellen, és biztosítva az igazságos felhasználást. Ez egy közös rendszertervezési komponens, számos algoritmussal és megfontolással.

## Miért fontos a sebességkorlátozás

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

## Sebességkorlátozási algoritmusok

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

## Megvalósítási megfontolások

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

## Miért számít

A sebességkorlátozás tervezésének megértése értékes, mert ez egy **közös rendszertervezési komponens** a rendszerek védelméhez és az igazságos felhasználás biztosításához, így fontos gyakorlati tudás.

A sebességkorlátozás — annak korlátozása, hogy egy kliens hány kérést intézhet egy időablakban — fontos szükségleteket addresses: **védelem az visszaélések ellen** (támadások megelőzése, mint brute force, scraping és DoS), **túlterhelés megelőzése** (rendszerstabilitás védelme), az **igazságos felhasználás biztosítása** (egyetlen kliens sem monopolizálhatja az erőforrásokat, támogatva a rétegzett limiteket, mint ingyenes vs fizetett), és költségszabályozás.

Ezek a sebességkorlátozást az API-k és szolgáltatások közös követelményévé teszik.

A **algoritmusok** és azok kompromisszumainak megértése — a **fixed window** (egyszerű, de határfelületi robbanásokat lehetővé tevő), **sliding window** (simább és pontosabb), **token bucket** (kontrollált robbanásokat lehetővé tevő, ugyanakkor az átlagos sebességet korlátozó — népszerű és rugalmas), és leaky bucket (kimenet simítása) — a kulcsfontosságú tervezési tudás, mivel a megfelelő algoritmus választása befolyásolja a viselkedést.

A **megvalósítási megfontolások** megértése különösen fontos: az **elosztott sebességkorlátozás** kezelése (limitek megosztva több szerver között, általában **Redis** használatával a gyors atomi számlálók megosztásához a szerver példányok között — mivel per-szerver limitek nem működnek az elosztott rendszerekben), kliensek azonosítása (API kulcs, felhasználó vagy IP alapján), egyértelmű válaszok visszaadása (HTTP 429 retry-after fejlécekkel), alkalmazási hely kiválasztása (gateway, load balancer vagy alkalmazás), és granularitás (felhasználónként, végpontonként, rétegzett).

Ezek az igazi elosztott rendszerekben működő sebességkorlátozás tervezését tükrözik.

A sebességkorlátozás egy gyakran szükséges komponens, amely gyakran megjelenik a rendszertervezési megbeszélésekben és interjúkban.

Mivel a sebességkorlátozás egy közös, fontos komponens a rendszerek védelméhez (visszaélések és túlterhelés ellen) és az igazságos felhasználás biztosításához, és mivel az algoritmusok, azok kompromisszumai, és különösen az elosztott megvalósítás (megosztott limitek Redis-en keresztül) megértése fontos annak jó tervezéséhez, a sebességkorlátozás tervezésének megértése értékes, gyakorlatban releváns rendszertervezési tudás — egy közös komponens a szolgáltatások védelméhez és az igazságos felhasználás biztosításához, az algoritmusok és az elosztott megvalósítás megértésének szükségességével, és egy gyakran megvitatott téma a robusztus, védett rendszerek építéséhez szükséges rendszertervezésben.