Cum funcționează rate limiting și HTTP caching într-un REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting protejează serverul de prea multe cereri; HTTP caching evită repetarea muncii pentru cereri la care a răspuns deja. Ambele sunt standardizate în HTTP și ambele sunt esențiale pentru un API de producție la scară.

## Rate limiting

Serverul limitează câte cereri poate face un client per fereastră și returnează **`429 Too Many Requests`** când se depășește. Anunță limitele prin headere, astfel încât un client bine-manierat să se poată auto-limita:

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

Header-ul `Retry-After` îi spune clientului exact cât să aștepte. Algoritmi comuni: **token bucket** (permite burst-uri până la dimensiunea bucket-ului, se reumple constant — alegerea uzuală), **sliding window** și **fixed window** (cel mai simplu, dar cu burst-uri la marginile ferestrei). Cheile sunt de obicei per API key, utilizator sau IP, cu contoare în Redis pentru o flotă distribuită.

## HTTP caching

Două mecanisme complementare:

**1. Expirare (`Cache-Control`)** — serverul spune cât timp rămâne proaspăt un răspuns, astfel încât clientul/CDN-ul îl reutilizează **fără nicio cerere**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validare (`ETag` / conditional requests)** — când prospețimea este incertă, clientul revalidează ieftin. Serverul etichetează un răspuns cu un **`ETag`** (o amprentă de versiune); clientul îl trimite înapoi în `If-None-Match`, iar dacă nu s-a schimbat, serverul returnează **`304 Not Modified`** **fără body**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← body gol, economisește bandwidth
```

```text
Proaspăt (în max-age)     → servit din cache, 0 cereri
Expirat dar ETag se potrivește → 304, răspuns mic, fără re-render
Expirat și schimbat       → 200 cu body nou + ETag nou
```

ETag-urile alimentează și **optimistic concurrency**: trimite `If-Match: "a1b2c3"` pe un `PUT`, iar serverul returnează `412 Precondition Failed` dacă altcineva a schimbat resursa primul — prevenind actualizările pierdute.

## De ce contează

Împreună, acestea sunt modul în care un REST API supraviețuiește la scară, așa că intervievatorii senior le folosesc pentru a verifica maturitatea operațională. Pentru rate limiting, semnalul este că îl tratezi ca pe un **contract cooperativ** — expunând headerele `RateLimit-*` și `Retry-After` ca clienții să se retragă elegant în loc să se izbească de un zid — și că poți numi un algoritm și unde stă contorul (Redis, per key) într-o implementare distribuită. Pentru caching, perspectiva cheie este **modelul pe două niveluri**: expirarea (`max-age`) elimină cererea complet, în timp ce validarea (`ETag`/`304`) face ieftine cererile inevitabile prin omiterea body-ului. Menționarea faptului că ETag-urile fac dublă slujbă pentru **optimistic concurrency** (`If-Match` → `412`) arată o stăpânire mai profundă a semanticii HTTP. Candidații care înțeleg aceste mecanisme sunt cei care pot construi API-uri ce rămân rapide și stabile sub trafic real, exact ce testează întrebarea.

Rate limiting

HTTP caching

De ce contează

Întrebări conexe