Thiết kế fallback khi API AI chậm hoặc hết hạn mức

Hứa điều hệ thống thực sự làm được

Một nút “Tạo báo cáo” không nên đứng im khi API bị chậm. Hãy cho người dùng biết tác vụ đang xử lý, giữ lại đầu vào và có điểm kết thúc rõ ràng khi không thể hoàn thành.

Phân loại lỗi trước khi retry

Lỗi xác thực hoặc đầu vào sai thường không được giải quyết bằng cách gửi lại cùng yêu cầu. Lỗi tạm thời như giới hạn tốc độ hoặc lỗi máy chủ có thể phù hợp với retry có giới hạn, tùy hướng dẫn nhà cung cấp.

Nếu SDK đã tự retry, hãy tính cả số lần đó trước khi thêm một lớp retry ở ứng dụng. Hai lớp độc lập có thể làm tổng thời gian và số request tăng ngoài dự kiến.

Chọn fallback theo ý nghĩa tác vụ

• Với nội dung sáng tạo, có thể đề nghị thử lại hoặc lưu bản nháp.
• Với tra cứu dữ liệu, có thể hiển thị tài liệu nguồn mà chưa tổng hợp.
• Với hành động thay đổi dữ liệu, xác minh trạng thái trước khi thử lại để tránh ghi trùng.

Không âm thầm đổi model nếu điều đó làm thay đổi chính sách dữ liệu, chi phí hoặc chất lượng mà người dùng đã được cam kết.

Thiết kế trạng thái giao diện

Phân biệt đang chờ, đang tạo, hoàn tất và thất bại. Một lỗi cần nói điều gì xảy ra, dữ liệu đã được giữ hay chưa và hành động tiếp theo. Không hiển thị stack trace hoặc token API cho người dùng.

Thử lỗi có chủ đích

Dùng adapter giả trong bộ kiểm thử để tạo timeout và mã lỗi. Kiểm tra nút được bật lại, biểu mẫu không mất nội dung và không có hai tác vụ chạy do người dùng bấm liên tiếp.

Theo dõi sau khi phát hành

Ghi model ID, mã lỗi, thời gian, token và mã yêu cầu; hạn chế ghi dữ liệu riêng tư. Đặt cảnh báo trên tỷ lệ lỗi và thời gian đuôi dài, không chỉ độ trễ trung bình.