API Rate Limiting Là Gì?
API Rate Limiting là cơ chế giới hạn số lượng yêu cầu (request) mà một người dùng hoặc một ứng dụng có thể gửi đến API trong một khoảng thời gian nhất định. Nói đơn giản, nó giống như cửa quán ăn giới hạn mỗi khách chỉ được gọi 5 món mỗi giờ — gọi quá sẽ bị từ chối.
Khi bạn dùng một ứng dụng gọi đến server thông qua API, server phải xử lý yêu cầu đó. Nếu có quá nhiều yêu cầu cùng lúc, server có thể quá tải và sập. Rate Limiting sinh ra để ngăn điều đó xảy ra.
Tại Sao Cần API Rate Limiting?
Chỉ cần ba lý do chính:
- Bảo vệ server: Tránh tình trạng quá tải, giữ hệ thống ổn định cho tất cả người dùng.
- Công bằng: Đảm bảo không ai “chiếm dụng” hết tài nguyên server, khiến người khác phải chờ đợi.
- Bảo mật: Chặn tấn công DDoS, brute force, hoặc lạm dụng API theo cách tự động hóa.
Mình từng thấy nhiều API công khai (như OpenAI, Twitter, GitHub) đều áp dụng rate limiting rất gắt. Lý do đơn giản: nếu không giới hạn, một script tự động có thể gửi hàng triệu request mỗi phút và làm sập toàn bộ hệ thống.
Rate Limiting Hoạt Động Thế Nào?
Có mấy thuật toán phổ biến mà các hệ thống thường dùng:
1. Fixed Window (Cửa sổ cố định)
Chia thời gian thành các khoảng cố định (ví dụ: mỗi phút). Trong mỗi khoảng, bạn chỉ được gửi tối đa N request. Nếu hết hạn mức, phải đợi sang khoảng tiếp theo.
Ví dụ: GitHub API cho phép 60 request/giờ đối với user chưa xác thực. Sau khi hết 60 request, bạn phải đợi sang giờ tiếp theo.
2. Sliding Window (Cửa sổ trượt)
Thay vì chia cứng theo phút hay giờ, cửa sổ trượt tính từ thời điểm hiện tại lùi về sau một khoảng thời gian. Linh hoạt hơn, tránh tình trạng người dùng “chạy đua” ở ranh giới giữa hai cửa sổ.
3. Token Bucket (Xô token)
Mỗi user có một “xô” chứa token. Mỗi request tốn 1 token. Token được bổ sung dần theo thời gian. Nếu xô rỗng, request bị từ chối. Thuật toán này cho phép burst (gửi nhiều request cùng lúc) nhưng vẫn kiểm soát được tốc độ trung bình.
4. Leaky Bucket (Xô rỉ)
Tương tự Token Bucket nhưng request được xử lý với tốc độ cố định, như nước chảy ra từ lỗ rỉ. Request đến quá nhanh sẽ tràn xô và bị bỏ qua. Phù hợp cho hệ thống cần tốc độ xử lý đều đặn.
Các Loại Giới Hạn Phổ Biến
Thường thấy mấy dạng sau trong thực tế:
- Theo IP: Giới hạn theo địa chỉ IP. Đơn giản nhưng không chính xác nếu nhiều user dùng chung IP (như NAT, VPN).
- Theo API Key: Mỗi API key có hạn mức riêng. Phổ biến với các dịch vụ SaaS.
- Theo User: Giới hạn theo tài khoản người dùng đã xác thực. Chính xác nhất.
- Theo Endpoint: Một số endpoint nhạy cảm (đăng nhập, reset password) có giới hạn riêng, khắt hơn.
HTTP Headers Báo Trạng Thái Rate Limit
Khi gọi API, server thường trả về thông tin rate limit qua HTTP headers. Mấy header phổ biến:
X-RateLimit-Limit: Tổng số request cho phép trong khoảng thời gian.X-RateLimit-Remaining: Số request còn lại.X-RateLimit-Reset: Thời điểm reset lại hạn mức (Unix timestamp).Retry-After: Bao nhiêu giây nữa mới được gửi lại (khi bị 429).
Nếu bạn từng gọi API và nhận về HTTP status 429 Too Many Requests, đó chính là rate limit đang hoạt động. Server bảo: “Bạn gửi quá nhanh rồi, chờ chút đi.”
Ví Dụ Thực Tế
Mấy ví dụ bạn chắc gặp hoài:
- OpenAI API: Giới hạn theo tier (hạng tài khoản). Tier 1 có thể giới hạn 60 request/phút, tier cao hơn thì nhiều hơn.
- GitHub API: 5.000 request/giờ cho user đã xác thực, 60 request/giờ cho anonymous.
- Twitter/X API: Các tier khác nhau có hạn mức khác nhau, từ vài chục đến vài trăm request mỗi 15 phút.
Mình hay gặp rate limit nhất khi build tool tự động đăng bài lên mạng xã hội. Nếu gửi quá nhanh, API trả 429 ngay. Lúc đó phải throttle (chậm lại) hoặc dùng queue để cách nhau từng giây.
Cách Xử Lý Khi Bị Rate Limit
Không có gì phức tạp, chỉ cần mấy bước:
- Đọc header Retry-After để biết cần chờ bao lâu.
- Dùng Exponential Backoff: Khi bị 429, chờ 1 giây rồi thử lại. Nếu vẫn 429, chờ 2 giây, rồi 4 giây, 8 giây… Tăng dần.
- Cache kết quả: Nếu dữ liệu ít thay đổi, cache lại thay vì gọi API liên tục.
- Batch request: Gộp nhiều yêu cầu nhỏ thành một request lớn nếu API hỗ trợ.
- Upgrade plan: Nếu cần nhiều hơn, nâng cấp gói API (tốn tiền nhưng hiệu quả nhất).
Best Practices Khi Thiết Kế API
Nếu bạn là người xây dựng API, mấy điểm này đáng lưu ý:
- Luôn thông báo rate limit qua HTTP headers để client biết mà điều chỉnh.
- Trả về thông báo lỗi rõ ràng kèm thời gian cần chờ.
- Đặt hạn mức hợp lý — không quá khắt (user khó chịu) nhưng cũng không quá lỏng (server rủi ro).
- Xem xét dùng Redis để track rate limit ở quy mô lớn, hiệu năng cao.
Kết Luận
API Rate Limiting là phần không thể thiếu của bất kỳ API production nào. Nó bảo vệ server, đảm bảo công bằng giữa các user, và ngăn lạm dụng. Dù bạn là người gọi API hay người xây API, hiểu rate limiting là kỹ năng cơ bản nhưng cực kỳ quan trọng.
Nếu bạn đang dùng API của bên thứ ba, hãy luôn xử lý HTTP 429 graceful — chờ đúng thời gian rồi retry. Còn nếu đang build API, đừng quên đặt rate limit ngay từ đầu, đừng đợi đến khi bị tấn công mới vội.
