Giới hạn tốc độ, lỗi 429 và nâng cấp gói
Cập nhật September 1, 2026 · đăng lần đầu September 1, 2026
Khi một dịch vụ bắt đầu trả về 429, phản xạ thường gặp là xem đây như một sự cố về tính khả dụng: nâng giới hạn, nâng gói, thêm cơ chế thử lại, khôi phục thông lượng. Đôi khi cách làm đó là đúng. Nhưng đó cũng là cơ chế khiến một vòng lặp chạy vượt tầm kiểm soát trở thành hóa đơn lên tới năm chữ số, vì thứ duy nhất đang chặn nó vừa bị gỡ bỏ.
Lỗi 429 thực sự cho bạn biết điều gì
Nó cho biết hệ thống đang cố tiêu tốn nhanh hơn mức được phép. Điều này xảy ra vì hai lý do rất khác nhau, và cần hai cách xử lý ngược hẳn nhau. Nhu cầu tăng thật sự — nhiều người dùng hơn, một đợt ra mắt, một đỉnh theo mùa — nghĩa là giới hạn thực sự quá thấp, và nâng lên sẽ mang lại doanh thu thật. Hành vi chạy vượt tầm kiểm soát — bão thử lại, một agent lặp vô hạn, một đợt backfill không có throttle, một bộ kiểm thử trỏ vào khóa production — nghĩa là giới hạn đang làm đúng nhiệm vụ của nó.
Chỉ nhìn tỷ lệ lỗi thì không phân biệt được hai trường hợp này. Nhưng nhìn chi phí trên mỗi đơn vị công việc thì dễ dàng phân biệt: khi tăng trưởng thật, tỷ lệ này gần như không đổi dù khối lượng tăng; khi chạy vượt tầm kiểm soát, tỷ lệ bị phá vỡ, chi phí cho mỗi tác vụ hoàn thành tăng vọt so với hôm qua. Chỉ số tỷ lệ này nên là điều kiện để quyết định mọi lần nâng gói.
Cơ chế thử lại làm mọi thứ tệ hơn, một cách âm thầm
Thử lại ngay khi gặp 429 mà không có backoff luỹ thừa và jitter sẽ biến một lần vượt giới hạn thành một cơn bão đồng bộ. Các yêu cầu thành công đều bị tính phí; nhiều yêu cầu thất bại vẫn đã tiêu tốn xử lý đầu vào. Và vì cơ chế thử lại thường được cài trong thư viện client chứ không nằm trong mã ứng dụng, sự khuếch đại này không xuất hiện ở bất kỳ tài liệu thiết kế tính năng nào.
Sử dụng giới hạn có chủ đích
Đặt giới hạn của riêng bạn thấp hơn giới hạn của nhà cung cấp, theo từng môi trường và từng tính năng, để thứ đầu tiên bị vỡ là giới hạn của bạn và bạn kiểm soát được bước tiếp theo. Giữ môi trường không phải production bị giới hạn chặt — một bản build kiểm thử lỗi thì rẻ, còn một luồng khách hàng bị nghẽn thì không. Cảnh báo dựa trên tỷ lệ chi phí trên mỗi tác vụ, không chỉ dựa trên số lỗi. Và khi nâng gói, hãy coi đó là một quyết định chi tiêu có người chịu trách nhiệm được nêu tên, vì đúng là như vậy.
Liên quan
Liên quan
Bạn muốn áp dụng điều này cho hệ thống của mình? Hãy mang theo hóa đơn nhà cung cấp, nhật ký gateway và các quy trình chính; chúng tôi sẽ xác định yếu tố chi phí và hướng tiết kiệm. Đặt lịch kiểm toán miễn phí →