Hogyan működik a rate limiting és a HTTP caching egy REST API-ban?

Question

IT Interview Practice · Accepted Answer

A rate limiting megvédi a servert a túl sok kéréstől; a HTTP caching elkerüli a munka megismétlését olyan kéréseknél, amelyeket már megválaszolt. Mindkettő szabványosítva van a HTTP-ben, és mindkettő elengedhetetlen egy éles, nagy méretű API-hoz.

## Rate limiting

A server korlátozza, hány kérést tehet egy kliens ablakonként, és **`429 Too Many Requests`**-et ad vissza túllépéskor. Headereken keresztül hirdeti a korlátokat, hogy egy jól viselkedő kliens önmagát fékezhesse:

```http
HTTP/1.1 200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 12
RateLimit-Reset: 30
```

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 30

{ "error": "rate limit exceeded, retry in 30s" }
```

A `Retry-After` header pontosan megmondja a kliensnek, mennyit kell várnia. Gyakori algoritmusok: **token bucket** (burstöket enged egy bucket-méretig, egyenletesen töltődik újra — a szokásos választás), **sliding window** és **fixed window** (a legegyszerűbb, de burstös az ablak szélein). A kulcsok általában API key, user vagy IP szerintiek, a számlálókkal Redisben egy elosztott flottához.

## HTTP caching

Két egymást kiegészítő mechanizmus:

**1. Lejárat (`Cache-Control`)** — a server megmondja, meddig marad friss egy válasz, így a kliens/CDN **kérés nélkül** újrahasználja:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Kiértékelés (`ETag` / conditional request-ek)** — amikor a frissesség bizonytalan, a kliens olcsón revalidál. A server egy **`ETag`**-gel (verzió-ujjlenyomat) látja el a választ; a kliens visszaküldi az `If-None-Match`-ben, és ha nem változott, a server **`304 Not Modified`**-et ad vissza **body nélkül**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← empty body, saves bandwidth
```

```text
Fresh (within max-age)   → served from cache, 0 requests
Stale but ETag matches   → 304, tiny response, no re-render
Stale and changed        → 200 with new body + new ETag
```

Az ETag-ek az **optimistic concurrency**-t is meghajtják: küldj `If-Match: "a1b2c3"`-t egy `PUT`-on, és a server `412 Precondition Failed`-et ad vissza, ha valaki más előbb megváltoztatta az erőforrást — megelőzve az elveszett frissítéseket (lost update).

## Miért fontos

Együtt ezek azok, amelyekkel egy REST API túléli a nagy méretet, ezért a senior interjúztatók ezekkel ellenőrzik az üzemeltetési érettséget. A rate limitingnál a jel az, hogy **kooperatív szerződésként** kezeled — kirakva a `RateLimit-*` és `Retry-After` headereket, hogy a kliensek elegánsan visszalépjenek, ahelyett, hogy falba vernék magukat —, és hogy meg tudsz nevezni egy algoritmust és azt, hol él a számláló (Redis, kulcsonként) egy elosztott telepítésben. A cachingnál a kulcsfelismerés a **kétszintű modell**: a lejárat (`max-age`) teljesen kiküszöböli a kérést, míg a kiértékelés (`ETag`/`304`) olcsóvá teszi az elkerülhetetlen kéréseket a body kihagyásával. Ha megemlíted, hogy az ETag-ek kettős feladatot látnak el az **optimistic concurrency**-hez (`If-Match` → `412`), az mélyebb HTTP-szemantikai tudást mutat. Azok a jelöltek, akik értik ezeket a mechanizmusokat, azok, akik olyan API-kat tudnak építeni, amelyek gyorsak és stabilak maradnak valós forgalom alatt — pontosan ez az, amit a kérdés tesztel.

Rate limiting

HTTP caching

Miért fontos

Kapcsolódó kérdések