Bagaimana rate limiting dan HTTP caching bekerja dalam sebuah REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting melindungi server dari terlalu banyak request; HTTP caching menghindari pengulangan pekerjaan untuk request yang sudah dijawabnya. Keduanya distandarkan dalam HTTP dan keduanya esensial untuk sebuah API produksi pada skala besar.

## Rate limiting

Server membatasi berapa banyak request yang boleh dibuat client per jendela dan mengembalikan **`429 Too Many Requests`** ketika terlampaui. Ia mengiklankan batas melalui header sehingga client yang berperilaku baik bisa membatasi dirinya sendiri:

```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` memberitahu client persis berapa lama harus menunggu. Algoritma umum: **token bucket** (mengizinkan burst hingga ukuran bucket, mengisi ulang secara stabil — pilihan biasa), **sliding window**, dan **fixed window** (paling sederhana tetapi bursty di tepi jendela). Key biasanya per API key, user, atau IP, dengan counter di Redis untuk armada terdistribusi.

## HTTP caching

Dua mekanisme yang saling melengkapi:

**1. Expiration (`Cache-Control`)** — server mengatakan berapa lama sebuah response tetap segar, sehingga client/CDN menggunakannya kembali dengan **tanpa request sama sekali**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / conditional request)** — ketika kesegaran tidak pasti, client merevalidasi dengan murah. Server menandai sebuah response dengan sebuah **`ETag`** (sidik jari versi); client mengirimnya kembali dalam `If-None-Match`, dan jika tidak berubah server mengembalikan **`304 Not Modified`** dengan **tanpa body**:

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

ETag juga menggerakkan **optimistic concurrency**: kirim `If-Match: "a1b2c3"` pada sebuah `PUT`, dan server mengembalikan `412 Precondition Failed` jika orang lain mengubah resource lebih dulu — mencegah update yang hilang.

## Mengapa ini penting

Bersama-sama, inilah cara sebuah REST API bertahan pada skala besar, sehingga pewawancara senior memakainya untuk memeriksa kematangan operasional. Untuk rate limiting, sinyalnya adalah bahwa Anda memperlakukannya sebagai sebuah **kontrak kooperatif** — memaparkan header `RateLimit-*` dan `Retry-After` agar client mundur dengan anggun alih-alih menghantam tembok — dan bahwa Anda bisa menyebut sebuah algoritma serta di mana counter berada (Redis, per key) dalam deployment terdistribusi. Untuk caching, wawasan kuncinya adalah **model dua tingkat**: expiration (`max-age`) menghilangkan request sepenuhnya, sementara validation (`ETag`/`304`) membuat request yang tak terhindarkan menjadi murah dengan melewati body. Menyebutkan bahwa ETag berfungsi ganda untuk **optimistic concurrency** (`If-Match` → `412`) menunjukkan penguasaan semantik HTTP yang lebih dalam. Kandidat yang memahami mekanisme ini adalah mereka yang bisa membangun API yang tetap cepat dan stabil di bawah traffic nyata, yang persis inilah yang diuji oleh pertanyaan tersebut.

Rate limiting

HTTP caching

Mengapa ini penting

Pertanyaan terkait