rate limiting และ HTTP caching ทำงานอย่างไรใน REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting ปกป้อง server จาก request ที่มากเกินไป ส่วน HTTP caching หลีกเลี่ยงการทำงานซ้ำสำหรับ request ที่เคยตอบไปแล้ว ทั้งสองถูกทำให้เป็นมาตรฐานใน HTTP และทั้งคู่จำเป็นสำหรับ API ระดับ production ที่สเกลใหญ่

## Rate limiting

server จำกัดจำนวน request ที่ client ทำได้ต่อหน้าต่างเวลา และคืน **`429 Too Many Requests`** เมื่อเกิน มันประกาศขีดจำกัดผ่าน header เพื่อให้ client ที่ประพฤติดีควบคุมตัวเองได้:

```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` บอก client อย่างแม่นยำว่าต้องรอนานเท่าไร อัลกอริทึมที่พบบ่อย: **token bucket** (อนุญาต burst ได้ถึงขนาดของ bucket แล้วเติมกลับอย่างสม่ำเสมอ — ตัวเลือกที่ใช้ทั่วไป), **sliding window**, และ **fixed window** (ง่ายที่สุดแต่ burst ที่ขอบของหน้าต่าง) คีย์มักเป็นราย API key, user, หรือ IP โดยเก็บ counter ไว้ใน Redis สำหรับกลุ่มเครื่องแบบกระจาย

## HTTP caching

สองกลไกที่เสริมกัน:

**1. การหมดอายุ (`Cache-Control`)** — server บอกว่า response ยังสด (fresh) นานแค่ไหน เพื่อให้ client/CDN นำกลับมาใช้ซ้ำ **โดยไม่ต้อง request เลย**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. การตรวจสอบ (`ETag` / conditional request)** — เมื่อความสดไม่แน่นอน client จะ revalidate อย่างประหยัด server ติดป้าย response ด้วย **`ETag`** (ลายนิ้วมือของเวอร์ชัน); client ส่งมันกลับไปใน `If-None-Match` และหากไม่เปลี่ยน server จะคืน **`304 Not Modified`** **โดยไม่มี 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 ยังขับเคลื่อน **optimistic concurrency**: ส่ง `If-Match: "a1b2c3"` บน `PUT` แล้ว server จะคืน `412 Precondition Failed` หากมีคนอื่นเปลี่ยนทรัพยากรก่อน — ป้องกันการอัปเดตที่สูญหาย (lost update)

## ทำไมจึงสำคัญ

เมื่อรวมกัน นี่คือวิธีที่ REST API รอดพ้นจากสเกลใหญ่ ผู้สัมภาษณ์ senior จึงใช้มันตรวจสอบวุฒิภาวะเชิงปฏิบัติการ สำหรับ rate limiting สัญญาณคือคุณมองมันเป็น **สัญญาแบบร่วมมือ** — เปิดเผย header `RateLimit-*` และ `Retry-After` เพื่อให้ client ถอยอย่างสุภาพแทนการโหมชนกำแพง — และระบุอัลกอริทึมกับที่อยู่ของ counter (Redis, ราย key) ในการติดตั้งแบบกระจายได้ สำหรับ caching ข้อคิดสำคัญคือ **โมเดลสองชั้น**: การหมดอายุ (`max-age`) กำจัด request ทิ้งไปเลย ส่วนการตรวจสอบ (`ETag`/`304`) ทำให้ request ที่เลี่ยงไม่ได้ราคาถูกลงด้วยการข้าม body การกล่าวถึงว่า ETag ทำหน้าที่คู่สำหรับ **optimistic concurrency** (`If-Match` → `412`) แสดงถึงความเชี่ยวชาญ semantics ของ HTTP ที่ลึกกว่า ผู้สมัครที่เข้าใจกลไกเหล่านี้คือคนที่สร้าง API ที่ยังเร็วและเสถียรภายใต้ traffic จริงได้ ซึ่งเป็นสิ่งที่คำถามนี้กำลังทดสอบพอดี

Rate limiting

HTTP caching

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง