Phân tích kỹ thuật | 05/06/2026

Tìm hiểu Rate Limits là gì trong API, lỗi 429 và các thuật toán phổ biến

Khi xây dựng hệ thống tích hợp API, có một tình huống gần như developer hay nhà đầu tư nào cũng gặp phải đó là mọi thứ chạy hoàn hảo trong môi trường test, nhưng vừa lên production với lưu lượng thực tế, hệ thống bắt đầu nhận về lỗi “429 Too Many Requests”. Đây không phải lỗi trong code mà là cơ chế có chủ đích của mọi nhà cung cấp API. Vậy Rate Limits là gì, tại sao nó tồn tại, các thuật toán nào được dùng để thực thi và làm thế nào để xây dựng hệ thống xử lý đúng cách. Tìm hiểu ngay!

Mục lục hiện

Rate Limits là gì?

Rate Limit (giới hạn tốc độ) là cơ chế kiểm soát số lượng request mà một client (ứng dụng, người dùng, hoặc IP) có thể gửi đến một API hoặc dịch vụ trong một khoảng thời gian nhất định. Khi vượt quá ngưỡng cho phép, server sẽ từ chối các request tiếp theo và thường bằng HTTP status code “429 Too Many Requests” cho đến khi cửa sổ thời gian được làm mới.

Hiểu đơn giản, Rate Limit giống như một quầy vé tàu có giới hạn số lượng khách phục vụ mỗi giờ. Nếu bạn đến quầy quá nhiều lần trong cùng một khung giờ, nhân viên sẽ yêu cầu bạn chờ đến lượt tiếp theo dù bạn là khách hàng hợp lệ. Tuy nhiên, hệ thống không từ chối bạn vĩnh viễn, chỉ là chậm một chút.

Lỗi 429 Too Many Requests là gì?

429 Too Many Requests là mã trạng thái HTTP cho biết người dùng hoặc ứng dụng đã gửi quá nhiều request đến máy chủ trong một khoảng thời gian ngắn và vượt quá giới hạn (Rate Limit) mà API hoặc dịch vụ cho phép.

Khi lỗi này xảy ra, máy chủ sẽ tạm thời từ chối các request mới cho đến khi hạn mức được làm mới hoặc thời gian chờ kết thúc. Đây là cơ chế được sử dụng phổ biến để bảo vệ hệ thống khỏi tình trạng quá tải, lạm dụng hoặc các cuộc tấn công tự động.

Ví dụ: Nếu một API chỉ cho phép 100 request/phút, nhưng ứng dụng gửi tới 150 request trong cùng một phút, 50 request vượt ngưỡng có thể nhận phản hồi:

HTTP/1.1 429 Too Many Requests

Retry-After: 60

Trong đó:

429 Too Many Requests: Thông báo đã vượt quá giới hạn truy cập.
Retry-After: Cho biết số giây cần chờ trước khi gửi lại request.

Tại sao Rate Limits tồn tại?

Bảo vệ hạ tầng khỏi quá tải: Một client duy nhất gửi hàng nghìn request mỗi giây có thể làm chậm hoặc sập server cho toàn bộ người dùng còn lại. Vì vậy, việc thiết lập Rate Limit là lớp phòng thủ đầu tiên trước các cuộc tấn công DDoS và các bot được cấu hình lỗi.
Đảm bảo công bằng giữa các client: Nếu không có Rate Limit, một ứng dụng duy nhất có thể chiếm toàn bộ tài nguyên và làm ảnh hưởng đến trải nghiệm của tất cả người dùng còn lại.
Kiểm soát chi phí sử dụng: Với các dịch vụ tính tiền theo lượng sử dụng (như API của OpenAI hay AWS), Rate Limit giúp tránh các kịch bản chi phí bùng nổ do bug vô tình khiến vòng lặp gọi API vô hạn.
Ngăn chặn lạm dụng khai thác: Rate Limit đóng vai trò như một lớp phòng vệ giúp ngăn chặn các cuộc tấn công dò mật khẩu (brute-force), tấn công nhồi nhét thông tin đăng nhập (credential stuffing) và các hành vi khai thác tự động từ bot.
Phân tầng dịch vụ theo tính năng: Cho phép nhà cung cấp phân biệt gói Free, Pro và Enterprise,… Gói càng cao thì ngưỡng request càng lớn, tạo ra mô hình kinh doanh bền vững.

Các đơn vị đo Rate Limit phổ biến

Trước khi đi vào thuật toán, cần nắm rõ các đơn vị mà các nhà cung cấp API thường dùng để định nghĩa giới hạn:

RPM (Requests Per Minute): Số lượng request tối đa được gửi tới API trong một phút. Đây là loại giới hạn phổ biến nhất, giúp ngăn hệ thống bị quá tải bởi lượng truy cập đột biến.
RPD (Requests Per Day): Tổng số request tối đa trong một ngày. Giới hạn này thường xuất hiện ở các gói miễn phí hoặc gói dùng thử nhằm kiểm soát chi phí vận hành.
TPM (Tokens Per Minute): Thường được áp dụng với các API AI như OpenAI hay Anthropic. TPM đo tổng số token đầu vào và đầu ra được xử lý mỗi phút, thay vì chỉ đếm số lượng request. Một request có prompt hoặc câu trả lời quá dài có thể tiêu tốn đáng kể hạn mức TPM dù RPM vẫn còn.
TPD (Tokens Per Day): Tổng số token tối đa được phép xử lý trong một ngày. Đây là giới hạn thường được các nhà cung cấp AI sử dụng để kiểm soát tổng mức tiêu thụ tài nguyên và chi phí của người dùng.
IPM (Images Per Minute): Số lượng hình ảnh tối đa có thể được tạo hoặc xử lý trong một phút. Chỉ số này thường áp dụng cho các API AI tạo ảnh hoặc phân tích hình ảnh như DALL·E, Midjourney API, Stability AI hay các dịch vụ Computer Vision.

Ví dụ:

API	Giới hạn mặc định
GitHub REST API	5.000 yêu cầu mỗi giờ dành cho người dùng đã xác thực.
Stripe	100 yêu cầu mỗi giây
Twitter/X	300 yêu cầu trong khoảng thời gian 15 phút
Google Maps	10 yêu cầu mỗi giây cho mỗi người dùng

Tham khảo:

4 thuật toán Rate Limiting phổ biến nhất

Rate Limit không chỉ là đếm số lượng request mà còn có nhiều thuật toán khác nhau, mỗi cái phù hợp với một bài toán cụ thể. Chẳng hạn như:

1. Fixed Window

Chia thời gian thành các khung cố định (ví dụ: mỗi phút một khung) và đếm số request trong khung hiện tại cho đến khi khi vượt ngưỡng thì từ chối. Bước sang khung tiếp theo, bộ đếm sẽ được reset về 0 để tiếp tục quy trình.

Ví dụ: Giới hạn 100 yêu cầu mỗi phút có nghĩa là các yêu cầu trong khoảng thời gian từ 12:00:00 đến 12:00:59 sẽ làm tăng bộ đếm lên một. Vào lúc 12:01:00, bộ đếm sẽ được đặt lại về 0.

Phương pháp này tiết kiệm tài nguyên tính toán và chỉ cần một bộ đếm và một mã định danh cửa sổ. Tuy nhiên, nó lại gây ra hiện tượng khuếch đại ranh giới (boundary burst): Một máy khách có thể gửi 100 yêu cầu lúc 12:00:59 và 100 yêu cầu khác lúc 12:01:00 và về mặt kỹ thuật, hệ thống chỉ cho phép 100 yêu cầu mỗi phút, nhưng thực tế có đến 200 yêu cầu trong vòng hai giây.

2. Sliding Window

Thay vì reset theo khung cố định, cửa sổ trượt liên tục theo thời gian thực. Tại bất kỳ thời điểm nào, hệ thống chỉ nhìn vào N request trong khoảng thời gian T tính ngược từ hiện tại.

Chính xác hơn Fixed Window và không có lỗ hổng boundary burst. Phù hợp khi cần kiểm soát nghiêm ngặt một IP hoặc user cụ thể. Tuy nhiên tốn bộ nhớ hơn vì phải lưu timestamp của từng request.

3. Token Bucket

Bạn hình dung một cái xô chứa token, mỗi request tiêu thụ một token và token được nạp lại với tốc độ cố định theo thời gian. Nếu xô còn token, request được xử lý; nếu xô rỗng, request bị từ chối.

Đây là thuật toán Rate Limiting phổ biến vì cho phép xử lý các đợt truy cập tăng đột biến một cách linh hoạt. Khi không sử dụng API, token sẽ được tích lũy dần. Nhờ đó, người dùng có thể gửi nhiều request liên tiếp trong thời gian ngắn khi cần mà vẫn nằm trong giới hạn cho phép.

4. Leaky Bucket

Với thuật toán này, các request được đưa vào hàng đợi và xử lý theo một tốc độ đầu ra cố định, bất kể tốc độ gửi request đầu vào cao đến đâu. Nếu hàng đợi đầy, các request mới sẽ bị từ chối. Leaky Bucket giúp duy trì tốc độ xử lý ổn định và đều đặn, phù hợp với các hệ thống phía sau (downstream) cần được bảo vệ khỏi các đợt truy cập tăng đột biến.

Ví dụ: API kết nối với hệ thống ngân hàng có thể sử dụng Leaky Bucket để đảm bảo số lượng giao dịch xử lý không bao giờ vượt quá một ngưỡng nhất định mỗi giây.

Tham khảo: Rate Limiting Algorithms: Token Bucket vs Sliding Window vs Fixed Window

Cách xử lý Rate Limit đúng cách trong hệ thống thực tế

Hiểu Rate Limit là gì vẫn chưa đủ. Trong thực tế, điều quan trọng là xây dựng cơ chế xử lý Rate Limit một cách bền vững để tránh làm gián đoạn hệ thống, giảm nguy cơ bị chặn API và tối ưu hiệu suất vận hành. Một số phương pháp phổ biến gồm:

Exponential Backoff với Jitter: Khi nhận lỗi 429, không nên retry ngay lập tức mà tăng dần thời gian chờ theo cấp số nhân (1s → 2s → 4s → 8s…) kết hợp thêm một khoảng ngẫu nhiên nhỏ (jitter) để tránh tình trạng hàng trăm client cùng retry đồng loạt vào một thời điểm.

python

import time, random

def call_with_backoff(fn, max_retries=5):

for attempt in range(max_retries):

try:

return fn()

except RateLimitError:

wait = (2 ** attempt) + random.uniform(0, 1)

time.sleep(wait)

raise Exception(“Max retries exceeded”)

Theo dõi header chủ động: Sau mỗi phản hồi từ API, hệ thống nên kiểm tra số lượng request còn được phép thực hiện thông qua các header như X-RateLimit-Remaining. Khi hạn mức chỉ còn khoảng 10 – 20%, nên chủ động giảm tốc độ gửi request thay vì chờ đến khi bị từ chối với lỗi 429.
Request Queuing: Với các tác vụ cần xử lý khối lượng dữ liệu lớn, chẳng hạn đồng bộ hoặc xử lý hàng chục nghìn bản ghi, nên đưa request vào hàng đợi và gửi theo tốc độ phù hợp với giới hạn của API thay vì gửi đồng loạt cùng lúc.
Lưu trữ tạm kết quả (Caching): Nhiều trường hợp vượt Rate Limit xảy ra do hệ thống liên tục yêu cầu lại cùng một dữ liệu. Việc lưu trữ tạm kết quả ở phía ứng dụng giúp giảm đáng kể số lượng API call không cần thiết, từ đó tiết kiệm tài nguyên và hạn chế nguy cơ chạm ngưỡng giới hạn.

FAQ – Những câu hỏi thường gặp về Rate Limits là gì

Rate Limit và Throttling khác nhau như thế nào?

Rate Limit thường đề cập đến ngưỡng vượt qua là bị từ chối ngay bằng lỗi 429 trong khi Throttling thường chỉ cơ chế làm chậm request (delay) thay vì từ chối hoàn toàn.

Rate Limit có áp dụng khác nhau cho từng endpoint không?

Có. Hầu hết các API hiện đại đều áp dụng Rate Limit khác nhau cho từng endpoint dựa trên mức độ tiêu tốn tài nguyên của từng thao tác. Những endpoint đơn giản như truy xuất dữ liệu thường có giới hạn cao hơn, trong khi các endpoint phức tạp như tìm kiếm, phân tích dữ liệu, xử lý AI,… thường có giới hạn thấp hơn để bảo vệ hệ thống khỏi quá tải.

Làm sao tăng Rate Limit nếu hệ thống cần nhiều hơn mức mặc định?

Hầu hết nhà cung cấp API có cơ chế nâng Rate Limit bằng cách nâng cấp gói dịch vụ (từ Free lên Pro/Enterprise), liên hệ trực tiếp để yêu cầu tăng quota với lý do hợp lý hoặc tự động tăng theo mức độ sử dụng lịch sử,…

Kết luận

Tóm lại, Rate Limits là gì? Đó là cơ chế bảo vệ sức khỏe của toàn bộ hệ thống, không chỉ của nhà cung cấp mà cả của ứng dụng bạn đang xây dựng. Việc hiểu rõ cách Rate Limit hoạt động như thế nào, cách xử lý,… là những kỹ năng nền tảng mà bất kỳ developer hay nhà đầu tư nào làm việc với API hiện đại. Đặc biệt trong lĩnh vực giao dịch tài chính hay bot trading – nơi mỗi mili-giây và mỗi lần bị block đều có hệ quả trực tiếp đến hiệu suất.