🔥 Rate Limiting – Khi API cần được "thở" đúng cách! 🔥

[dangquangminh]

🔥 Rate Limiting – Khi API cần được "thở" đúng cách! 🔥
💡 DevOps và Automation Engineer – bạn có bao giờ gặp tình huống API từ chối phản hồi và báo lỗi 429 Too Many Requests chưa? Đây là lúc mà cơ chế rate limiting cứu cả hệ thống!

---

🧠 Rate Limiting là gì?


Rate limiting là kỹ thuật kiểm soát số lượng request mà một client có thể gửi đến API trong một khoảng thời gian nhất định. Mục tiêu là bảo vệ tài nguyên hệ thống khỏi lạm dụng, lỗi lập trình, hay tệ hơn – tấn công DoS/DDoS.

---

1. Client-side vs Server-side Rate Limiting


👉 Client-side rate limiting:

• Được triển khai trực tiếp trong ứng dụng phía client.
• Hạn chế việc spam API qua đồng hồ đếm, thanh loading hoặc delay thủ công.
• Hiệu quả nếu client "ngoan", nhưng không chống lại client bị xâm nhập hay độc hại.

👉 Server-side rate limiting:

• Phía server chủ động giới hạn số lượng request.
• Hiệu quả cao hơn, ngăn ngừa:
  • Tấn công từ chối dịch vụ (DoS),
  • Hành vi bất thường như xoá hàng loạt tài nguyên (dấu hiệu bị compromise).
  • Quá tải hệ thống khi người dùng tăng đột biến.

Ví dụ:

• Mỗi user chỉ được phép gọi 1000 API/ngày.
• Gói premium có thể mở rộng giới hạn này.

---

2. Chiến thuật throttle API thông minh


Các cách giới hạn request thường dùng:

• HTTP headers:
  Dùng X-RateLimit-Limit và X-RateLimit-Remaining để thông báo số lượng request còn lại.
• Message queue:
  Xếp hàng các request thay vì xử lý ngay để tránh nghẽn cổ chai.
• Thuật toán kiểm soát:
  • Fixed Window
  • Leaky Bucket
  • Sliding Log
    (sẽ đào sâu hơn ở bài sau!)
• Reverse Proxy & Load Balancer (như NGINX):
  Hỗ trợ rate limiting như một tính năng mặc định.

---

3. Phản hồi khi vượt giới hạn


Khi user gọi API quá giới hạn:

• Server trả về HTTP 429 Too Many Requests
• Kèm theo Retry-After header → chỉ định thời gian chờ trước khi gọi lại.

---

4. Xử lý sự cố & kiểm tra sức khỏe API


🛠 Đôi khi API sẽ bị "mệt":

• Đang cập nhật hệ thống,
• Quá tải,
• Mất kết nối mạng.

✅ Best practice:

• Gửi request kiểm tra /api/status
• Theo dõi HTTP response codes:
  • 200 OK: ổn.
  • 404 Not Found, 500 Internal Server Error: API down hoặc sai endpoint.

⏱ Chiến lược retry hiệu quả:

• Linear backoff: thử lại sau mỗi 60 giây.
• Exponential backoff: 1 → 2 → 4 → 8 → 16s...

Nếu gặp timeout:

• 408 Request Timeout
• 504 Gateway Timeout

---

5. Giới hạn kích thước payload – Payload Limiting


🔥 Một nguy cơ tiềm ẩn – payload quá lớn (ví dụ: upload ảnh HD, XML file nặng...) có thể:

• Làm server chậm hoặc tắt ngóm vì quá tải RAM.
• Bị gián đoạn khi truyền tải.
• Bị tấn công bằng dữ liệu độc hại.

👮♂️ API nên giới hạn kích thước payload để:

• Bảo mật
• Tối ưu hiệu năng
• Ngăn chặn tấn công khai thác bộ nhớ

❌ Nếu vượt giới hạn, server trả về HTTP 413 Request Entity Too Large

---

✅ Tóm lại – Dev cần nhớ:

• Client-side rate limiting: giới hạn từ phía client.
• Server-side rate limiting: bảo vệ server hiệu quả hơn.
• Payload limiting: giới hạn kích thước request để tăng bảo mật và hiệu suất.

📌 Câu hỏi ôn tập cuối bài
Sự khác nhau giữa client-side rate limiting và payload limiting là gì?
✅ Client-side rate limiting giới hạn số lượng request gửi đi, còn payload limiting giới hạn kích thước nội dung mỗi request.

---

🎯 Gợi ý thực hành:


Viết một đoạn script Python nhỏ:

• Gọi API /api/status mỗi 30 giây.
• Kiểm tra response code.
• Áp dụng exponential backoff nếu thất bại.