Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA cho một startup giao đồ ăn ở TP.HCM. Sản phẩm vừa lên báo, lượng truy cập tăng vọt vào giờ trưa. Đột nhiên app đứng hình: người dùng không đặt được món, nhà hàng không nhận được đơn, đội kỹ thuật báo "server quá tải vì có một đối tác đang gọi API liên tục mỗi giây để đồng bộ menu". Đó chính là lúc bạn nhận ra: một API không có rate limiting (giới hạn tần suất gọi) giống như một quán ăn không có cửa — ai cũng tràn vào cùng lúc và cả hệ thống sụp đổ.
Với vai trò BA, bạn không phải là người code phần rate limiting, nhưng bạn là người quyết định luật chơi: mỗi khách hàng được gọi bao nhiêu lần, vượt quá thì sao, gói trả phí khác gói miễn phí thế nào. Những quyết định này nằm thẳng trong tài liệu nghiệp vụ và spec API mà bạn viết. Nếu bạn không hiểu rate limiting, bạn sẽ viết ra những yêu cầu hoặc quá lỏng (gây sập hệ thống), hoặc quá chặt (làm khách hàng khó chịu và rời bỏ). Bài này giúp bạn nắm vững khái niệm, thuật toán, và cách diễn đạt rate limiting thành yêu cầu rõ ràng cho đội kỹ thuật.
Khái niệm cốt lõi
Rate limiting là kỹ thuật giới hạn số lượng request (yêu cầu) mà một bên gọi (consumer) được phép gửi tới API trong một khoảng thời gian nhất định. Ví dụ: "100 request mỗi giờ", "10 request mỗi giây". Khái niệm gần nghĩa là throttling (điều tiết) — làm chậm hoặc tạm chặn request khi vượt ngưỡng, thay vì từ chối hẳn.
Bốn lý do chính khiến mọi API đều cần rate limiting
1. Bảo vệ server khỏi quá tải và tấn công. Một đợt tấn công DDoS (Distributed Denial of Service) bản chất là dội hàng triệu request để làm sập server. Rate limiting là tuyến phòng thủ đầu tiên: mỗi nguồn chỉ được gọi tới một mức nhất định, vượt thì bị chặn. Ngay cả khi không bị tấn công, một client bị lỗi (ví dụ vòng lặp vô hạn gọi API) cũng có thể vô tình "tự DDoS" hệ thống.
2. Công bằng giữa các consumer (fair use). Nếu API phục vụ nhiều khách hàng, bạn không muốn một khách "tham lam" chiếm hết tài nguyên khiến những khách khác bị chậm. Rate limiting đảm bảo tài nguyên được chia đều, không ai làm ảnh hưởng ai.
3. Phân tầng giá theo gói (tiered pricing). Đây là phần BA cần đặc biệt quan tâm vì nó gắn trực tiếp với mô hình kinh doanh. Một API thương mại thường bán theo gói: gói Free cho 100 request/giờ, gói Pro cho 10.000 request/giờ, gói Enterprise không giới hạn. Rate limiting chính là cơ chế kỹ thuật biến mô hình giá này thành hiện thực. Không có rate limiting thì chẳng có gì để bán.
4. Bảo vệ tài nguyên đắt đỏ phía sau. Mỗi request có thể kéo theo một truy vấn database nặng, một lệnh gọi sang dịch vụ bên thứ ba có tính phí, hoặc tính toán tốn CPU. Giới hạn tần suất giúp bảo vệ những tài nguyên này khỏi bị bào mòn và giữ chi phí vận hành trong tầm kiểm soát.
Các thuật toán phổ biến (BA nên biết để nói chuyện với dev)
Bạn không cần code chúng, nhưng cần hiểu sự khác biệt để chọn đúng:
- Fixed Window (cửa sổ cố định): Đếm số request trong một khung thời gian cố định, ví dụ mỗi phút reset một lần. Đơn giản nhưng có nhược điểm "burst tại biên": nếu giới hạn là 100/phút, client có thể gửi 100 request lúc 10:00:59 và thêm 100 request lúc 10:01:00 — tức 200 request trong 1 giây.
- Sliding Window (cửa sổ trượt): Tính theo khoảng thời gian trượt liên tục, ví dụ "100 request trong 60 giây gần nhất tính từ thời điểm hiện tại". Mượt hơn, tránh được vấn đề burst tại biên.
- Token Bucket (xô token): Mỗi consumer có một "xô" chứa token, mỗi request tiêu một token, token được nạp lại đều đặn theo thời gian. Cho phép xử lý burst ngắn (khi xô đang đầy) nhưng vẫn giữ tốc độ trung bình. Đây là thuật toán được dùng nhiều nhất trong thực tế.
- Leaky Bucket (xô rò): Request xếp hàng và được xử lý với tốc độ cố định, như nước rò khỏi xô đều đặn. Làm mượt lưu lượng nhưng có thể gây độ trễ.
Khách hàng biết mình bị giới hạn bằng cách nào?
API thường trả về thông tin giới hạn qua HTTP headers (chúng ta đã học về headers ở các bài trước). Bộ header chuẩn phổ biến:
X-RateLimit-Limit: tổng số request được phép trong khung thời gian (ví dụ 100).X-RateLimit-Remaining: số request còn lại (ví dụ 37).X-RateLimit-Reset: thời điểm bộ đếm reset (thường là timestamp).Retry-After: khi đã bị chặn, header này cho biết phải đợi bao nhiêu giây mới được gọi lại.
Tình huống thực tế
Tình huống 1: Cổng thanh toán VNPAY và đối tác ví điện tử
Giả sử một cổng thanh toán lớn tại Việt Nam (kiểu VNPAY) mở API cho hàng nghìn website thương mại điện tử tích hợp. Vào dịp sale 12/12, một sàn TMĐT viết một đoạn code lỗi: thay vì hỏi trạng thái giao dịch mỗi 5 giây, nó hỏi liên tục không nghỉ — tạo ra hàng chục nghìn request/phút từ một nguồn duy nhất.
Nếu không có rate limiting, truy vấn này có thể làm chậm database giao dịch của cả cổng thanh toán, ảnh hưởng tới mọi đối tác khác đang xử lý hàng tỷ đồng tiền hàng. Nhờ đã đặt giới hạn (ví dụ 600 request/phút cho mỗi merchant), cổng thanh toán tự động trả về 429 cho sàn TMĐT kia, kèm Retry-After: 30. Các merchant khác hoàn toàn không bị ảnh hưởng.
Bài học rút ra: Rate limiting không chỉ chống tấn công có chủ đích, mà còn chống chính những lỗi vô tình của đối tác. Là BA viết spec tích hợp thanh toán, bạn phải ghi rõ "hệ thống phải xử lý được status 429 và lùi lịch gọi lại theo Retry-After" — nếu không, đội của bạn sẽ là bên gây sự cố.
Tình huống 2: Mô hình tiered pricing của một API SaaS
Một công ty SaaS Việt Nam bán API tra cứu thông tin doanh nghiệp (mã số thuế, ngành nghề). Họ thiết kế ba gói:
- Free: 100 request/ngày — đủ cho lập trình viên thử nghiệm.
- Startup: 50.000 request/tháng, tối đa 10 request/giây — cho ứng dụng nhỏ.
- Enterprise: 5 triệu request/tháng, 100 request/giây — cho ngân hàng, công ty bảo hiểm.
Khi bộ phận kinh doanh muốn tạo gói mới "Pro: 500.000 request/tháng", chính BA là người định nghĩa con số giới hạn, hành vi khi vượt ngưỡng (chặn hay throttle), và thông điệp lỗi hiển thị. Những con số này không phải dev tự nghĩ ra — chúng đến từ phân tích nghiệp vụ và chiến lược giá.
Bài học rút ra: Rate limiting là cầu nối giữa kỹ thuật và mô hình doanh thu. Mỗi con số trong bảng giá tương ứng với một cấu hình rate limit cụ thể, và BA là người dịch chiến lược giá thành yêu cầu kỹ thuật.
Tình huống 3: API công khai bị bot quét dữ liệu
Một nền tảng bất động sản (kiểu Batdongsan hay Chợ Tốt) có API công khai trả về danh sách tin đăng. Một đối thủ thuê bot cào toàn bộ dữ liệu để sao chép sang trang của họ — gọi API hàng triệu lần để lấy hết tin đăng.
Đội kỹ thuật phát hiện và áp rate limit theo địa chỉ IP và theo API key: mỗi IP chỉ được 1.000 request/giờ cho endpoint danh sách. Bot lập tức nhận hàng loạt 429. Họ thử chia nhỏ qua nhiều IP, nhưng kết hợp thêm giới hạn theo API key và phát hiện hành vi bất thường, nền tảng vẫn chặn được phần lớn lưu lượng cào dữ liệu.
Bài học rút ra: Rate limiting còn là công cụ bảo vệ tài sản dữ liệu — một mối quan tâm nghiệp vụ thực sự, không chỉ là vấn đề kỹ thuật. BA cần xác định endpoint nào "nhạy cảm" (trả về nhiều dữ liệu giá trị) để đặt giới hạn chặt hơn.
Hướng dẫn từng bước
Khi bạn là BA và cần đưa rate limiting vào tài liệu yêu cầu hoặc spec API, hãy đi theo các bước sau:
Bước 1 — Xác định đối tượng bị giới hạn (limit key). Giới hạn tính theo cái gì? Theo người dùng (user), theo API key, theo địa chỉ IP, hay theo tổ chức (tenant)? Mỗi lựa chọn có ý nghĩa nghiệp vụ khác nhau. API thương mại thường giới hạn theo API key vì nó gắn với hợp đồng và gói cước.
Bước 2 — Xác định ngưỡng và khung thời gian. Bao nhiêu request trong bao lâu? Hãy lấy con số từ dữ liệu thực: nhu cầu trung bình của khách hàng là bao nhiêu, đỉnh điểm thế nào, server chịu được tới đâu. Đặt ngưỡng thấp hơn ngưỡng chịu đựng của hệ thống một biên độ an toàn.
Bước 3 — Quyết định hành vi khi vượt ngưỡng. Có hai lựa chọn chính: hard limit (chặn thẳng, trả 429) hay throttle/queue (làm chậm, xếp hàng). Khách trả phí cao thường nên được throttle nhẹ nhàng thay vì chặn cứng để giữ trải nghiệm tốt.
Bước 4 — Định nghĩa response trả về. Status code dùng 429 Too Many Requests. Body cần thông điệp rõ ràng ("Bạn đã vượt giới hạn 100 request/giờ, vui lòng thử lại sau 5 phút"). Headers cần Retry-After và bộ X-RateLimit-*.
Bước 5 — Phân tầng theo gói (nếu có tiered pricing). Lập bảng ánh xạ: mỗi gói cước tương ứng ngưỡng nào. Ghi rõ điều gì xảy ra khi khách muốn nâng cấp giữa chừng.
Bước 6 — Mô tả hành vi mong đợi phía consumer. Nếu hệ thống của bạn là bên gọi API người khác, spec phải ghi: khi nhận 429, phải đợi theo Retry-After, áp dụng exponential backoff (đợi tăng dần: 1s, 2s, 4s, 8s...) thay vì gọi lại ngay lập tức.
Bước 7 — Định nghĩa cách giám sát và cảnh báo. Ai được thông báo khi một khách hàng liên tục chạm ngưỡng? Đó có thể là tín hiệu họ cần nâng cấp gói (cơ hội bán hàng) hoặc đang gặp lỗi tích hợp (cần hỗ trợ).
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm 429 với 503. Status 429 Too Many Requests nghĩa là "bạn gọi quá nhiều, đây là lỗi của bạn". Còn 503 Service Unavailable nghĩa là "server tôi đang quá tải/bảo trì". Đừng dùng lẫn lộn trong spec, vì cách xử lý phía client hoàn toàn khác nhau.
Lỗi 2 — Quên định nghĩa hành vi khi vượt ngưỡng. Nhiều BA chỉ viết "giới hạn 100 request/giờ" rồi dừng lại. Dev sẽ phải đoán: chặn hay throttle, trả lỗi gì, header nào. Luôn mô tả đầy đủ cả phần "khi vượt thì sao".
Lỗi 3 — Đặt ngưỡng bằng cảm tính. Con số 100 hay 1.000 phải dựa trên dữ liệu sử dụng và năng lực hệ thống, không phải con số tròn cho đẹp. Hãy hỏi đội kỹ thuật về sức chịu tải và hỏi đội kinh doanh về nhu cầu thực của khách.
Lỗi 4 — Bỏ qua trải nghiệm khi bị chặn. Một response 429 với body trống khiến lập trình viên tích hợp bối rối. Luôn yêu cầu thông điệp lỗi rõ ràng, cho biết giới hạn là bao nhiêu và khi nào được gọi lại.
Mẹo 1: Đề xuất hiển thị header X-RateLimit-Remaining để client tự biết mình còn bao nhiêu lượt — giúp họ chủ động điều tiết thay vì chỉ biết khi đã bị chặn.
Mẹo 2: Với khách hàng lớn, cân nhắc cơ chế "burst cho phép tạm vượt ngưỡng ngắn" (token bucket) thay vì chặn cứng — vừa bảo vệ hệ thống vừa giữ trải nghiệm tốt.
Mẹo 3: Coi việc khách liên tục chạm ngưỡng là một tín hiệu kinh doanh: hoặc là cơ hội bán gói cao hơn, hoặc là dấu hiệu họ cần được hỗ trợ kỹ thuật.
Bài tập thực hành
- Viết spec rate limit. Cho một API gửi tin nhắn SMS marketing, hãy viết phần đặc tả rate limiting đầy đủ: limit key (theo cái gì), ngưỡng, khung thời gian, hành vi khi vượt, status code, headers, và thông điệp lỗi.
- Thiết kế bảng tiered pricing. Một startup bán API dịch thuật muốn ba gói Free / Pro / Business. Hãy đề xuất con số rate limit cho từng gói và giải thích lý do nghiệp vụ đằng sau mỗi con số.
- Phân tích tình huống. Một đối tác phàn nàn "API của các bạn thỉnh thoảng trả 429 dù chúng tôi gọi không nhiều". Hãy liệt kê các nguyên nhân có thể (gợi ý: fixed window burst tại biên, giới hạn theo IP dùng chung, nhiều instance cùng gọi) và đề xuất câu hỏi bạn sẽ hỏi đội kỹ thuật.
- So sánh thuật toán. Giải thích bằng ngôn ngữ nghiệp vụ (không dùng code) sự khác biệt giữa Fixed Window và Token Bucket, và trường hợp nào nên dùng cái nào.
Tóm tắt
Rate limiting là cơ chế giới hạn số request mà một consumer được gọi tới API trong một khoảng thời gian, phục vụ bốn mục tiêu cốt lõi: bảo vệ server khỏi quá tải và DDoS, đảm bảo công bằng giữa các consumer, hiện thực hóa mô hình tiered pricing, và bảo vệ database cùng các tài nguyên đắt đỏ phía sau.
Về kỹ thuật, có nhiều thuật toán (Fixed Window, Sliding Window, Token Bucket, Leaky Bucket) với những đánh đổi khác nhau giữa độ đơn giản và độ mượt. Khi vượt ngưỡng, API trả về status 429 Too Many Requests kèm header Retry-After và bộ X-RateLimit-* để client biết đường điều tiết.
Với BA, điểm mấu chốt là: rate limiting không chỉ là chuyện kỹ thuật mà là quyết định nghiệp vụ. Bạn là người định nghĩa giới hạn theo gói cước, hành vi khi vượt ngưỡng, thông điệp lỗi, và cách hệ thống của mình ứng xử khi nhận 429 từ bên khác. Hãy luôn viết spec đầy đủ cả phần "khi vượt thì sao", lấy con số từ dữ liệu thật, và nhìn việc khách chạm ngưỡng như một tín hiệu kinh doanh đáng giá.