Khi một ứng dụng bắt đầu có người dùng thật, vấn đề không chỉ là xử lý đúng request, mà còn là xử lý với nhịp độ hợp lý. Một ô tìm kiếm bị gọi API liên tục, một bot thử đăng nhập hàng nghìn lần, hoặc một client lỗi lặp request vô hạn đều có thể làm hệ thống chậm, tốn tài nguyên và gây ảnh hưởng đến người dùng khác. Rate limiting là một lớp bảo vệ quan trọng để giới hạn số lượng request trong một khoảng thời gian nhất định. Nói đơn giản, rate limiting trả lời câu hỏi: “Ai được gọi API này bao nhiêu lần trong bao lâu?” Ví dụ thực tế: - API đăng nhập: tối đa 5 lần thử sai trong 1 phút cho mỗi tài khoản hoặc IP. - API gửi mã OTP: tối đa 1 lần mỗi 60 giây, 5 lần mỗi ngày. - API tìm kiếm sản phẩm: tối đa 30 request mỗi phút cho mỗi người dùng. - API public không cần đăng nhập: giới hạn theo IP để tránh bị quét dữ liệu hàng loạt. Điểm quan trọng là không nên áp một con số chung cho toàn hệ thống. Mỗi loại endpoint có mức rủi ro và chi phí khác nhau. Gửi email, tạo đơn hàng, xuất file, gọi dịch vụ bên thứ ba thường cần giới hạn chặt hơn so với đọc dữ liệu đơn giản. Một số chiến lược phổ biến: 1. Giới hạn theo IP Phù hợp với API công khai hoặc trước khi người dùng đăng nhập. Cách này dễ triển khai nhưng không hoàn hảo, vì nhiều người dùng có thể dùng chung một IP, ví dụ trong công ty hoặc mạng di động. 2. Giới hạn theo user ID Phù hợp với chức năng sau đăng nhập. Cách này công bằng hơn vì mỗi tài khoản có hạn mức riêng. Tuy nhiên vẫn cần kết hợp với kiểm tra hành vi bất thường nếu tài khoản bị lạm dụng. 3. Giới hạn theo hành động Thay vì chỉ giới hạn toàn bộ request, hãy giới hạn theo hành động nhạy cảm. Ví dụ, người dùng có thể xem trang nhiều lần nhưng không nên được gửi OTP liên tục hoặc thử thanh toán quá nhiều lần trong thời gian ngắn. 4. Giới hạn theo cấp độ tài khoản Với sản phẩm SaaS hoặc API thương mại, tài khoản miễn phí, trả phí và nội bộ có thể có hạn mức khác nhau. Điều này giúp kiểm soát chi phí và tạo ranh giới rõ ràng cho người dùng. Khi bị giới hạn, phản hồi cũng cần được thiết kế tử tế. Đừng chỉ trả về “Too many requests” rồi kết thúc. Nên trả HTTP status 429 và kèm thông tin hữu ích như người dùng cần chờ bao lâu trước khi thử lại. Với giao diện web/app, có thể hiển thị thông báo: “Bạn thao tác hơi nhanh. Vui lòng thử lại sau 30 giây.” Nếu là nút gửi OTP, hãy disable nút và hiển thị bộ đếm ngược. Một lỗi thường gặp là chỉ làm rate limiting ở frontend. Điều này không đủ, vì người dùng hoặc bot có thể gọi thẳng API. Frontend chỉ nên hỗ trợ trải nghiệm, ví dụ debounce, disable nút, hiển thị đếm ngược. Quyết định giới hạn thật phải nằm ở backend hoặc API gateway. Cũng cần tránh giới hạn quá gắt khiến người dùng thật bị chặn oan. Ví dụ, nếu trang checkout gọi nhiều API nhỏ cùng lúc, giới hạn theo tổng request quá thấp có thể làm quá trình mua hàng lỗi ngẫu nhiên. Trước khi áp dụng, hãy quan sát log, xác định lưu lượng bình thường, sau đó đặt ngưỡng có khoảng đệm hợp lý. Một checklist áp dụng nhanh: - Xác định endpoint nào tốn tài nguyên hoặc dễ bị lạm dụng. - Chọn khóa giới hạn phù hợp: IP, user ID, token, số điện thoại, email hoặc kết hợp nhiều yếu tố. - Trả về mã 429 khi vượt giới hạn. - Cho client biết thời gian nên thử lại. - Ghi log các trường hợp bị chặn để phát hiện bot hoặc cấu hình sai. - Thiết kế thông báo rõ ràng trên giao diện. - Có cơ chế nới hạn mức cho tài khoản đáng tin cậy nếu sản phẩm cần. Rate limiting không phải là giải pháp bảo mật toàn diện, nhưng là một lớp phòng thủ rất thực tế. Làm tốt phần này giúp hệ thống ổn định hơn, giảm lạm dụng và giữ trải nghiệm công bằng cho người dùng thật.