Kepiye rate limiting lan HTTP caching mlaku ing REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting ngayomi server saka request sing kakehan; HTTP caching ngindhari mbaleni pakaryan kanggo request sing wis dijawab. Loro-lorone distandarake ing HTTP lan loro-lorone penting kanggo API produksi ing skala gedhe.

## Rate limiting

Server matesi pira request sing kena digawe client saben jendhela lan mbalekake **`429 Too Many Requests`** nalika ngluwihi. Dheweke ngumumake wates liwat header supaya client sing kelakuan apik bisa ngerem dhewe:

```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 `Retry-After` ngandhani client kanthi persis suwene kudu ngenteni. Algoritma umum: **token bucket** (ngidini burst nganti ukuran bucket, ngisi maneh kanthi ajeg — pilihan biasa), **sliding window**, lan **fixed window** (paling prasaja nanging burst ing pinggir jendhela). Kunci biasane saben API key, user, utawa IP, kanthi counter ing Redis kanggo armada terdistribusi.

## HTTP caching

Rong mekanisme sing saling nglengkapi:

**1. Kadaluwarsa (`Cache-Control`)** — server ngomong suwene response tetep seger, saengga client/CDN nganggo maneh kanthi **ora ana request babar pisan**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validasi (`ETag` / conditional request)** — nalika kesegeran ora mesthi, client revalidasi kanthi murah. Server nandhani response nganggo **`ETag`** (sidik jari versi); client ngirim maneh ing `If-None-Match`, lan yen ora owah server mbalekake **`304 Not Modified`** kanthi **ora ana body**:

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

```text
Isih seger (ing njero max-age)  → dilayani saka cache, 0 request
Kadaluwarsa nanging ETag cocog  → 304, response cilik, ora render ulang
Kadaluwarsa lan wis owah        → 200 kanthi body anyar + ETag anyar
```

ETag uga nguwataké **optimistic concurrency**: kirim `If-Match: "a1b2c3"` ing `PUT`, lan server mbalekake `412 Precondition Failed` yen wong liya ngowahi resource dhisik — nyegah update sing ilang.

## Kenapa iki penting

Bebarengan iki carane REST API slamet saka skala, mula pewawancara senior nganggo dheweke kanggo mriksa kematangan operasional. Kanggo rate limiting, sinyale yaiku kowe nganggep iku minangka **kontrak kooperatif** — mbabar header `RateLimit-*` lan `Retry-After` supaya client mundur kanthi apik tinimbang nabrak tembok — lan yen kowe bisa nyebut algoritma lan ing ngendi counter manggon (Redis, saben key) ing panyebaran terdistribusi. Kanggo caching, wawasan utama yaiku **model rong tingkat**: kadaluwarsa (`max-age`) ngilangi request kanthi total, dene validasi (`ETag`/`304`) ndadekake request sing ora bisa diendhani dadi murah kanthi ngliwati body. Nyebut yen ETag nglakoni tugas rangkep kanggo **optimistic concurrency** (`If-Match` → `412`) nuduhake panguwasan semantik HTTP sing luwih jero. Kandidat sing mangerteni mekanisme iki yaiku sing bisa mbangun API sing tetep cepet lan stabil ing sangisore traffic nyata, persis sing diuji pitakonan iki.

Rate limiting

HTTP caching

Kenapa iki penting

Pitakon sing gegandhengan