Kaip veikia rate limiting ir HTTP caching REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting apsaugo serverį nuo per daug užklausų; HTTP caching išvengia darbo kartojimo užklausoms, į kurias jau atsakyta. Abu standartizuoti HTTP ir abu esminiai production API dideliu masteliu.

## Rate limiting

Serveris riboja, kiek užklausų klientas gali atlikti per langą, ir grąžina **`429 Too Many Requests`**, kai viršijama. Jis skelbia ribas per header, kad gerai besielgiantis klientas galėtų save stabdyti:

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

`Retry-After` header sako klientui tiksliai, kiek laukti. Dažni algoritmai: **token bucket** (leidžia bursts iki bucket dydžio, tolygiai papildo — įprastas pasirinkimas), **sliding window** ir **fixed window** (paprasčiausias, bet burstinis ties lango kraštais). Raktai paprastai pagal API key, user ar IP, su skaitikliais Redis paskirstytam parkui.

## HTTP caching

Du vienas kitą papildantys mechanizmai:

**1. Galiojimas (`Cache-Control`)** — serveris sako, kiek laiko atsakymas lieka šviežias, kad klientas/CDN jį pakartotinai naudotų **be jokios užklausos**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Patikra (`ETag` / conditional requests)** — kai šviežumas neaiškus, klientas pigiai revaliduoja. Serveris pažymi atsakymą **`ETag`** (versijos pirštų atspaudu); klientas siunčia jį atgal `If-None-Match`, ir jei nepakito, serveris grąžina **`304 Not Modified`** **be kūno**:

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

ETags taip pat maitina **optimistic concurrency**: siųsk `If-Match: "a1b2c3"` su `PUT`, ir serveris grąžina `412 Precondition Failed`, jei kas nors kitas pakeitė išteklių pirmas — užkertant kelią prarastiems atnaujinimams (lost updates).

## Kodėl tai svarbu

Kartu tai yra tai, kaip REST API išgyvena mastelį, todėl senior interviuotojai naudoja juos operaciniam brandumui patikrinti. Rate limiting atveju signalas yra tai, kad traktuojate jį kaip **bendradarbiavimo sutartį** — atskleisdami `RateLimit-*` ir `Retry-After` header, kad klientai grakščiai atsitrauktų, o ne daužytųsi į sieną — ir mokate įvardyti algoritmą bei kur gyvena skaitiklis (Redis, pagal raktą) paskirstytame diegime. Caching atveju pagrindinė įžvalga yra **dviejų pakopų modelis**: galiojimas (`max-age`) visiškai pašalina užklausą, o patikra (`ETag`/`304`) daro neišvengiamas užklausas pigias praleisdama kūną. Paminėjimas, kad ETags atlieka dvigubą pareigą **optimistic concurrency** (`If-Match` → `412`), rodo gilesnį HTTP semantikos valdymą. Kandidatai, suprantantys šiuos mechanizmus, yra tie, kurie gali kurti API, liekančias greitas ir stabilias esant realiam srautui, o būtent tai šis klausimas ir tikrina.

Rate limiting

HTTP caching

Kodėl tai svarbu

Susiję klausimai