Trong phát triển web/app, nhiều lỗi không đến từ một request sai, mà đến từ quá nhiều request đúng được gửi trong thời gian ngắn. Người dùng bấm liên tục, bot quét API, form đăng nhập bị thử mật khẩu hàng loạt, hoặc một client bị lỗi vòng lặp gọi API không ngừng. Rate limiting là cơ chế giới hạn tần suất sử dụng tài nguyên để hệ thống ổn định và an toàn hơn. Nói đơn giản, rate limiting trả lời câu hỏi: “Ai được làm gì, bao nhiêu lần, trong khoảng thời gian nào?”. Ví dụ: - Một IP chỉ được gọi API đăng nhập 10 lần trong 1 phút. - Một tài khoản chỉ được gửi 5 mã OTP trong 10 phút. - Một API public chỉ cho phép 100 request/phút cho mỗi API key. - Một endpoint tìm kiếm chỉ cho phép 30 request/phút để tránh bị lạm dụng. Điểm quan trọng là không nên áp dụng một giới hạn duy nhất cho toàn hệ thống. Mỗi chức năng có rủi ro và chi phí khác nhau. API xem thông tin công khai có thể giới hạn nhẹ hơn, trong khi đăng nhập, gửi email, tạo đơn hàng, gửi OTP cần chặt chẽ hơn. Một thiết kế thực tế thường cần xác định các yếu tố sau: - Định danh người gọi: dùng user ID nếu đã đăng nhập, API key nếu là tích hợp bên ngoài, IP nếu chưa xác thực. Với mobile app hoặc người dùng dùng chung mạng, chỉ dựa vào IP có thể gây chặn nhầm. - Phạm vi giới hạn: giới hạn theo endpoint, theo nhóm hành động, hoặc theo toàn bộ hệ thống. Ví dụ /login và /send-otp nên có rule riêng. - Cửa sổ thời gian: 10 lần/phút, 100 lần/giờ, 1000 lần/ngày. Một số trường hợp nên kết hợp nhiều cửa sổ để tránh lạm dụng kéo dài. - Cách phản hồi: khi vượt giới hạn, nên trả về HTTP 429 Too Many Requests, kèm thông báo rõ ràng và thời gian có thể thử lại. Ví dụ thông báo tốt hơn “Có lỗi xảy ra” là: “Bạn đã yêu cầu mã xác thực quá nhiều lần. Vui lòng thử lại sau 5 phút.” Với API, nên trả thêm header hoặc field như retry_after để client biết nên chờ bao lâu trước khi gọi lại. Về kỹ thuật triển khai, nếu ứng dụng chỉ chạy một server, có thể lưu bộ đếm tạm trong memory. Nhưng với hệ thống nhiều instance, cần lưu ở nơi dùng chung như Redis để mọi server nhìn thấy cùng một trạng thái. Nếu không, người dùng có thể vượt giới hạn bằng cách request được phân phối sang nhiều server khác nhau. Một số lỗi thường gặp khi làm rate limiting: - Chặn quá gắt ở trang đăng nhập, khiến người dùng thật bị khóa chỉ vì nhập sai vài lần. - Không phân biệt user đã đăng nhập và IP công cộng, gây ảnh hưởng đến văn phòng, trường học hoặc mạng di động dùng chung IP. - Không log các lần vượt giới hạn, khiến đội kỹ thuật không nhìn thấy dấu hiệu tấn công hoặc lỗi client. - Không có ngoại lệ hợp lý cho hệ thống nội bộ, cron job, webhook hoặc đối tác đáng tin cậy. - Chỉ giới hạn ở frontend. Việc này không đủ vì bot có thể gọi thẳng backend. Một lời khuyên thực tế là hãy bắt đầu từ các điểm có rủi ro cao: đăng nhập, quên mật khẩu, gửi OTP, tạo nội dung, upload file, tìm kiếm nặng, API public. Sau đó theo dõi log để điều chỉnh ngưỡng. Rate limit không nên là con số đoán mò rồi bỏ quên; nó cần được kiểm tra theo hành vi người dùng thật. Ngoài ra, rate limiting nên đi cùng các lớp bảo vệ khác như captcha có điều kiện, khóa tạm thời theo tài khoản, kiểm tra bất thường, queue cho tác vụ nặng và cảnh báo khi có nhiều request bị từ chối. Mục tiêu không phải là gây khó chịu cho người dùng, mà là giữ hệ thống hoạt động ổn định khi gặp thao tác bất thường. Tóm lại, rate limiting là một phần nhỏ nhưng rất đáng đầu tư trong web/app development. Làm tốt cơ chế này giúp giảm spam, hạn chế brute force, bảo vệ tài nguyên máy chủ và tạo trải nghiệm công bằng hơn cho người dùng thật.