Thiết kế các tích hợp SMM API sống sót qua thất bại

Phiên bản đầu tiên của mọi tích hợp API đều giả định đường đi suôn sẻ: bạn gửi một yêu cầu, bạn nhận một phản hồi, đơn hàng được đặt. Môi trường sản xuất dạy bạn điều ngược lại. Mạng rớt, endpoint hết thời gian chờ, và thất bại nguy hiểm nhất là thất bại mơ hồ: yêu cầu có thể đã thành công hoặc chưa trước khi kết nối bị đứt. Thiết kế cho sự mơ hồ đó chính là toàn bộ công việc.

Idempotency là tuyến phòng thủ cốt lõi. Hãy gắn một khóa duy nhất vào mỗi yêu cầu đặt hàng và để máy chủ coi việc lặp lại khóa đó là cùng một thao tác, chứ không phải một thao tác mới. Giờ đây một lần thử lại sau khi hết thời gian chờ là an toàn: nếu yêu cầu gốc đã đi qua, bạn nhận lại đơn hàng đã có thay vì bị tính phí trùng lặp. Không có điều này, mỗi lần thử lại là một canh bạc với số dư của bạn.

Xếp lớp thử lại với backoff lên trên. Các lỗi tạm thời (một giới hạn tốc độ 429, một 503, một lần reset mạng) nên được thử lại với độ trễ tăng dần và một mức trần, chứ không dội bom tức thì. Các lỗi vĩnh viễn (một 400 bad request, một phản hồi không đủ số dư) nên thất bại nhanh và đưa lên cho con người, vì thử lại chúng chỉ tốn thời gian và che khuất vấn đề thực sự.

Cuối cùng, hãy đối soát. Ghi log mọi yêu cầu và phản hồi kèm idempotency key và order ID của nó, và chạy một tác vụ định kỳ so sánh hồ sơ của bạn với các trạng thái đơn hàng của panel. Đối soát là thứ bắt được đơn hàng đã thành công trên panel nhưng không ghi nhận được ở phía bạn. API của SocialGO trả về order ID và trạng thái nhất quán chính là để vòng lặp này dễ dàng xây dựng: đó là khác biệt giữa một hệ thống tự động bạn tin tưởng và một hệ thống tự động bạn phải trông chừng.