Giới hạn lưu lượng tích hợp mà không che lỗi quan trọng

Một tích hợp có thể trông khỏe vì tiến trình nền vẫn thử lại. Trong khi đó, hóa đơn hoặc cập nhật chờ lâu hơn mức nghiệp vụ chấp nhận. Thiết kế giới hạn lưu lượng hữu ích phải quản lý nhu cầu và giữ bằng chứng về lý do công việc chưa xong. Không nên đổi tên mọi lỗi thành giới hạn tạm thời.

Đọc chính xác tín hiệu nhà cung cấp

OWASP khuyến nghị phản hồi 429 Too Many Requests khi yêu cầu API đến quá nhanh.[7] Nhà cung cấp có thể định nghĩa tín hiệu khác. GitHub mô tả cách xử lý giới hạn chính và phụ cùng hướng dẫn cụ thể về header phản hồi.[6] Đừng sao chép cách hiểu của một nhà cung cấp sang mọi tích hợp.

Ghi trạng thái phản hồi, loại lỗi an toàn, header hạn mức liên quan và nhóm thao tác. Một lỗi 403 có thể cần sửa quyền thay vì chờ rồi thử lại.[7] Dựa vào chi tiết phản hồi được nhà cung cấp mô tả để phân biệt. Giữ lỗi ban đầu hiển thị khi bộ điều phối dời lần thử tiếp theo.

Kiểm soát tiếp nhận trước khi cạn hạn mức

Nên có bộ điều phối chung cho các lệnh gọi dùng cùng hạn mức nhà cung cấp. Tách công việc phục vụ người dùng khỏi đồng bộ hàng loạt nếu mức ưu tiên khác nhau. Dành công suất có chủ đích thay vì để một lần nạp bù lớn dùng hết lượt yêu cầu.

Giới hạn số lệnh đồng thời và theo dõi tuổi công việc trong hàng đợi. Xác định hạn mức áp dụng theo thông tin xác thực, khách hàng, endpoint hay phạm vi khác trong tài liệu. Nếu nhiều tiến trình cùng chia hạn mức, phải phối hợp ngân sách thay vì cấp toàn bộ hạn mức cho từng tiến trình. Hàng đợi chỉ hấp thụ đột biến khi còn dung lượng và thời gian chờ chấp nhận được. Quy định điều gì xảy ra khi hết khả năng đó.

Nếu hàng đợi chạm giới hạn, chọn phản hồi từ chối tiếp nhận rõ ràng hoặc tạm dừng có kiểm soát. Âm thầm bỏ công việc sẽ khiến việc giải thích và đối soát sau đó khó hơn.

Không để thử lại che khuất sự cố

GitHub hướng dẫn chờ theo retry-after khi có và cuối cùng báo lỗi sau số lần thử giới hạn nếu vẫn gặp giới hạn phụ.[6] Điều chỉnh chính sách theo hướng dẫn nhà cung cấp đó. Tách lỗi xác thực lặp lại, lỗi dữ liệu và thao tác không hỗ trợ thành công việc cần sửa.

• Theo dõi hạn mức đã dùng và tuổi mục nghiệp vụ chờ lâu nhất.
• Giữ trạng thái và chi tiết lỗi nhà cung cấp sau khi dời lịch nội bộ.
• Giới hạn số lần thử và đưa mục hết lượt vào hàng đợi ngoại lệ có người phụ trách.
• Kiểm thử tranh chấp khi nạp lớn và khôi phục sau lúc hạn mức được đặt lại.

Ví dụ giả định: đồng bộ danh mục

Ví dụ giả định: nhà phân phối nạp cập nhật sản phẩm trong khi nhân viên bán hàng kiểm tra tồn kho khẩn. Nhóm đặt ưu tiên khác nhau trong cùng ngân sách nhà cung cấp. Phản hồi hết hạn mức làm chậm cập nhật danh mục, nhưng thông tin xác thực bị thu hồi lập tức tạo sự cố cấu hình.

Bảng vận hành hiển thị cả tuổi hàng đợi và mốc danh mục thành công cuối. Nhờ vậy, vòng thử lại âm thầm không bị hiểu là tiến triển thành công. Xử lý ưu tiên làm điều phối phức tạp hơn và có thể khiến công việc hàng loạt không được chạy nếu không dành công suất riêng. Hãy bắt đầu bằng việc liệt kê mục nào có thể chờ, rồi đặt ngưỡng chậm dễ thấy cho từng nhóm.