Bagaimana rate limiting dan HTTP caching berfungsi dalam REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting melindungi server daripada terlalu banyak request; HTTP caching mengelakkan mengulang kerja untuk request yang telah dijawab. Kedua-duanya dipiawaikan dalam HTTP dan kedua-duanya penting untuk API production pada skala besar.

## Rate limiting

Server menghadkan berapa banyak request yang boleh dibuat client bagi setiap tetingkap dan memulangkan **`429 Too Many Requests`** apabila melebihi. Ia mengiklankan had melalui header supaya client yang berkelakuan baik boleh mengehad diri:

```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 dengan tepat berapa lama untuk menunggu. Algoritma lazim: **token bucket** (membenarkan burst sehingga saiz bucket, mengisi semula secara mantap — pilihan biasa), **sliding window**, dan **fixed window** (paling ringkas tetapi bergelombang di tepi tetingkap). Key biasanya bagi setiap API key, user, atau IP, dengan kaunter dalam Redis untuk armada teragih.

## HTTP caching

Dua mekanisme saling melengkapi:

**1. Tamat tempoh (`Cache-Control`)** — server menyatakan berapa lama response kekal segar, jadi client/CDN menggunakannya semula dengan **tiada request langsung**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Pengesahan (`ETag` / conditional request)** — apabila kesegaran tidak pasti, client mengesah semula dengan murah. Server menandakan response dengan **`ETag`** (cap jari versi); client menghantarnya semula dalam `If-None-Match`, dan jika tidak berubah server memulangkan **`304 Not Modified`** dengan **tiada body**:

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

```text
Segar (dalam max-age)      → dihidang dari cache, 0 request
Basi tetapi ETag padan     → 304, response kecil, tiada render semula
Basi dan telah berubah     → 200 dengan body baharu + ETag baharu
```

ETag juga menggerakkan **optimistic concurrency**: hantar `If-Match: "a1b2c3"` pada `PUT`, dan server memulangkan `412 Precondition Failed` jika orang lain mengubah sumber terlebih dahulu — menghalang kehilangan kemas kini (lost update).

## Mengapa ia penting

Bersama-sama, inilah cara REST API bertahan pada skala besar, jadi penemu duga senior menggunakannya untuk menyemak kematangan operasi. Untuk rate limiting, isyaratnya ialah anda menganggapnya sebagai **kontrak kerjasama** — mendedahkan header `RateLimit-*` dan `Retry-After` supaya client berundur dengan anggun dan bukannya menghentam tembok — dan bahawa anda boleh menamakan algoritma dan di mana kaunter berada (Redis, bagi setiap key) dalam penggunaan teragih. Untuk caching, cerapan utama ialah **model dua peringkat**: tamat tempoh (`max-age`) menghapuskan request sepenuhnya, manakala pengesahan (`ETag`/`304`) menjadikan request yang tidak dapat dielakkan itu murah dengan melangkau body. Menyebut bahawa ETag melakukan tugas berganda untuk **optimistic concurrency** (`If-Match` → `412`) menunjukkan penguasaan semantik HTTP yang lebih mendalam. Calon yang memahami mekanisme ini ialah mereka yang boleh membina API yang kekal pantas dan stabil di bawah trafik sebenar, itulah tepatnya yang diuji oleh soalan ini.

Rate limiting

HTTP caching

Mengapa ia penting

Soalan berkaitan