1. 09:48 06/08/2026
Khi ứng dụng bắt đầu có người dùng thật, một vấn đề rất dễ gặp là có những endpoint bị gọi quá nhiều: người dùng bấm liên tục, frontend lỗi vòng lặp, bot quét dữ liệu, hoặc một client tích hợp API sai cách. Nếu không có cơ chế giới hạn tần suất, vài luồng request bất thường có thể làm chậm cả hệ thống.
Rate limiting là kỹ thuật giới hạn số request mà một người dùng, IP, token hoặc client được phép gửi trong một khoảng thời gian nhất định. Mục tiêu không chỉ là “chặn cho đỡ tải”, mà là bảo vệ tài nguyên quan trọng và giúp hệ thống phục vụ công bằng hơn.
Ví dụ thực tế:
- API đăng nhập: giới hạn số lần thử sai để giảm nguy cơ brute force.
- API gửi OTP/email: tránh bị lạm dụng gây tốn chi phí hoặc spam người nhận.
- API tìm kiếm: hạn chế việc bot quét liên tục làm database quá tải.
- API tạo đơn hàng/thanh toán: giảm rủi ro request trùng hoặc hành vi bất thường.
Một số cách áp dụng phổ biến:
1. Giới hạn theo IP
Phù hợp với endpoint công khai, chưa đăng nhập. Ví dụ: mỗi IP chỉ được gọi API đăng nhập một số lần trong vài phút. Tuy nhiên, cần cẩn thận vì nhiều người dùng có thể dùng chung IP, đặc biệt trong mạng công ty, trường học hoặc nhà mạng di động.
2. Giới hạn theo user ID hoặc API key
Phù hợp hơn với hệ thống đã đăng nhập hoặc API cho đối tác. Cách này công bằng hơn vì mỗi tài khoản có quota riêng. Ví dụ: tài khoản miễn phí được gọi 1.000 request/ngày, tài khoản trả phí được nhiều hơn.
3. Giới hạn theo endpoint
Không phải API nào cũng cần cùng một ngưỡng. Endpoint đọc thông tin hồ sơ có thể cho phép cao hơn, trong khi gửi OTP, export báo cáo hoặc tạo thanh toán nên chặt hơn.
4. Trả lỗi rõ ràng cho client
Khi vượt giới hạn, nên trả HTTP 429 Too Many Requests. Nếu có thể, kèm thông tin như thời điểm được thử lại. Frontend có thể dùng thông tin này để hiển thị thông báo thân thiện: “Bạn thao tác quá nhanh, vui lòng thử lại sau 30 giây” thay vì báo lỗi chung chung.
Một vài lời khuyên khi triển khai:
- Đừng đặt ngưỡng quá thấp ngay từ đầu nếu chưa có dữ liệu hành vi người dùng.
- Nên log lại các lần bị rate limit để phát hiện bot, lỗi frontend hoặc client tích hợp sai.
- Với thao tác quan trọng, kết hợp rate limiting với captcha, xác thực nhiều bước hoặc idempotency key nếu phù hợp.
- Nếu hệ thống chạy nhiều server, không nên lưu bộ đếm trong memory cục bộ, vì mỗi server sẽ đếm riêng. Hãy cân nhắc dùng Redis hoặc một tầng gateway/API proxy có hỗ trợ rate limit.
- Thiết kế thông báo lỗi sao cho người dùng hiểu họ cần làm gì tiếp theo.
Một điểm quan trọng: rate limiting không thay thế validation, authentication hay phân quyền. Nó chỉ là một lớp bảo vệ trong tổng thể kiến trúc an toàn và ổn định hơn.
Nếu mới bắt đầu, bạn có thể chọn vài endpoint rủi ro cao như đăng nhập, gửi OTP, tìm kiếm, tạo tài nguyên mới để áp dụng trước. Sau đó theo dõi log, điều chỉnh ngưỡng và mở rộng dần. Làm tốt rate limiting sẽ giúp ứng dụng chịu lỗi tốt hơn, giảm lạm dụng và tránh để một nhóm request bất thường ảnh hưởng đến toàn bộ người dùng.