Rate limiting và HTTP caching hoạt động thế nào trong REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting bảo vệ server khỏi quá nhiều request; HTTP caching tránh lặp lại công việc cho những request đã trả lời rồi. Cả hai đều được chuẩn hoá trong HTTP và đều thiết yếu cho một API production ở quy mô lớn.

## Rate limiting

Server giới hạn số request một client được thực hiện trong mỗi cửa sổ thời gian và trả **`429 Too Many Requests`** khi vượt. Nó công bố giới hạn qua header để client biết điều tiết:

```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` cho client biết chính xác phải chờ bao lâu. Các thuật toán phổ biến: **token bucket** (cho phép burst tới kích thước bucket, nạp lại đều — lựa chọn thường dùng), **sliding window**, và **fixed window** (đơn giản nhất nhưng burst ở mép cửa sổ). Khoá thường theo API key, user, hoặc IP, với counter trong Redis cho một cụm phân tán.

## HTTP caching

Hai cơ chế bổ trợ nhau:

**1. Hết hạn (`Cache-Control`)** — server nói response còn tươi bao lâu, để client/CDN tái sử dụng **không cần request nào cả**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Kiểm chứng (`ETag` / conditional request)** — khi độ tươi không chắc, client revalidate với chi phí thấp. Server gắn cho response một **`ETag`** (dấu vân tay phiên bản); client gửi lại nó trong `If-None-Match`, và nếu không đổi server trả **`304 Not Modified`** **không có body**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← body rỗng, tiết kiệm băng thông
```

```text
Còn tươi (trong max-age)  → phục vụ từ cache, 0 request
Hết hạn nhưng ETag khớp   → 304, response tí hon, không render lại
Hết hạn và đã đổi         → 200 với body mới + ETag mới
```

ETag cũng tiếp sức cho **optimistic concurrency**: gửi `If-Match: "a1b2c3"` trên một `PUT`, và server trả `412 Precondition Failed` nếu người khác đã đổi tài nguyên trước — ngăn mất cập nhật (lost update).

## Tại sao điều này quan trọng

Cùng nhau, đây là cách một REST API sống sót khi quy mô lớn, nên người phỏng vấn senior dùng chúng để kiểm tra độ chín vận hành. Với rate limiting, tín hiệu là bạn coi nó như một **hợp đồng hợp tác** — phơi bày header `RateLimit-*` và `Retry-After` để client lùi lại lịch sự thay vì đâm đầu vào tường — và nêu được thuật toán cùng nơi đặt counter (Redis, theo từng key) trong triển khai phân tán. Với caching, cái nhìn cốt lõi là **mô hình hai tầng**: hết hạn (`max-age`) loại bỏ hẳn request, còn kiểm chứng (`ETag`/`304`) làm các request không tránh được trở nên rẻ bằng cách bỏ qua body. Nhắc rằng ETag còn kiêm nhiệm **optimistic concurrency** (`If-Match` → `412`) cho thấy nắm sâu ngữ nghĩa HTTP. Ứng viên hiểu các cơ chế này chính là người xây được API luôn nhanh và ổn định dưới traffic thật, đúng thứ câu hỏi đang kiểm tra.

Rate limiting

HTTP caching

Tại sao điều này quan trọng

Câu hỏi liên quan