Jak działają rate limiting i cache'owanie HTTP w REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting chroni serwer przed zbyt wieloma żądaniami; cache'owanie HTTP unika powtarzania pracy dla żądań, na które już odpowiedział. Oba są ustandaryzowane w HTTP i oba są niezbędne dla produkcyjnego API przy skali.

## Rate limiting

Serwer ogranicza, ile żądań klient może wykonać w oknie, i zwraca **`429 Too Many Requests`** po przekroczeniu. Ogłasza limity przez nagłówki, by dobrze zachowujący się klient mógł sam się dławić:

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

Nagłówek `Retry-After` mówi klientowi dokładnie, jak długo czekać. Popularne algorytmy: **token bucket** (pozwala na bursty do rozmiaru kubełka, uzupełnia się równomiernie — zwykły wybór), **sliding window** i **fixed window** (najprostszy, ale burstowy na krawędziach okna). Klucze są zwykle per klucz API, użytkownik lub IP, z licznikami w Redisie dla rozproszonej floty.

## Cache'owanie HTTP

Dwa uzupełniające się mechanizmy:

**1. Wygaśnięcie (`Cache-Control`)** — serwer mówi, jak długo odpowiedź pozostaje świeża, więc klient/CDN wykorzystuje ją ponownie **bez żadnego żądania**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Walidacja (`ETag` / żądania warunkowe)** — gdy świeżość jest niepewna, klient tanio rewaliduje. Serwer taguje odpowiedź **`ETag`** (odcisk wersji); klient odsyła go w `If-None-Match`, a jeśli nic się nie zmieniło, serwer zwraca **`304 Not Modified`** **bez ciała**:

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

ETagi napędzają też **optymistyczną współbieżność (optimistic concurrency)**: wyślij `If-Match: "a1b2c3"` przy `PUT`, a serwer zwróci `412 Precondition Failed`, jeśli ktoś inny zmienił zasób wcześniej — zapobiegając utraconym aktualizacjom (lost updates).

## Dlaczego to ważne

Razem to sposób, w jaki REST API przetrwa skalę, więc rozmówcy senior używają ich, by sprawdzić dojrzałość operacyjną. Dla rate limitingu sygnałem jest to, że traktujesz go jak **kontrakt oparty na współpracy** — udostępniając nagłówki `RateLimit-*` i `Retry-After`, by klienci wycofywali się łagodnie, zamiast walić w ścianę — i że potrafisz nazwać algorytm oraz gdzie żyje licznik (Redis, per klucz) we wdrożeniu rozproszonym. Dla cache'owania kluczowym spostrzeżeniem jest **model dwupoziomowy**: wygaśnięcie (`max-age`) eliminuje żądanie całkowicie, podczas gdy walidacja (`ETag`/`304`) czyni nieuniknione żądania tanimi, pomijając ciało. Wzmianka, że ETagi pełnią podwójną rolę przy **optymistycznej współbieżności** (`If-Match` → `412`), pokazuje głębsze opanowanie semantyki HTTP. Kandydaci, którzy rozumieją te mechanizmy, to ci, którzy potrafią budować API pozostające szybkimi i stabilnymi pod prawdziwym ruchem, co jest dokładnie tym, co to pytanie testuje.

Rate limiting

Cache'owanie HTTP

Dlaczego to ważne

Powiązane pytania