IOSOR

IOSOR Kiến thức

Webhook SMS đến: thử lại, thứ tự sự kiện, và tính bất biến khi nhận

Hướng dẫn xây dựng cho các đội B2B xử lý SMS đến: tại sao việc thử lại xảy ra, tại sao thứ tự sự kiện không được đảm bảo, và làm thế nào để làm cho điểm cuối nhận của bạn có tính bất biến thay vì nhân đôi cuộc trò chuyện và xử lý STOP.

Mọi trình xử lý tin nhắn đến cuối cùng đều gặp phải cùng ba điều bất ngờ: cùng một webhook kích hoạt hai lần, sự kiện "delivered" đến sau sự kiện "failed" mà nó lẽ ra phải thay thế, và phản hồi STOP của khách hàng được xử lý hai lần vì hai máy chủ nhận được cùng một lần thử lại. Không có điều nào trong số này là lỗi của nền tảng gửi webhook cho bạn — đó là hành vi bình thường của bất kỳ hệ thống phân phối "ít nhất một lần" nào, và điểm cuối nhận của bạn phải được xây dựng cho thực tế này ngay từ ngày đầu tiên.

IOSOR phân phối SMS đến, từ khóa STOP/HELP, và các sự kiện phân phối dưới dạng webhook trả trước white-label — hành vi thử lại và sắp xếp thứ tự bên dưới là những gì bất kỳ tích hợp B2B nghiêm túc nào cũng nên giả định, bất kể nền tảng nào đứng sau nó.

Tại sao webhook thử lại ngay từ đầu

Nhà cung cấp webhook không thể biết chắc chắn liệu điểm cuối của bạn đã xử lý một lần phân phối hay chưa. Máy chủ của bạn có thể trả về 200 sau khi commit vào cơ sở dữ liệu mà sau đó bị rollback; bộ cân bằng tải có thể làm mất phản hồi trên đường trở về mặc dù trình xử lý của bạn đã thành công; một lần triển khai có thể khởi động lại tiến trình của bạn giữa chừng yêu cầu.

Ba chế độ lỗi bạn phải thiết kế cho

Chế độ lỗi Điều gì xảy ra Điều gì bị hỏng nếu bạn bỏ qua
Phân phối trùng lặp Cùng một ID sự kiện đến 2+ lần Phản hồi bị đếm gấp đôi, xử lý STOP trùng lặp, luồng hội thoại trùng lặp
Sự kiện không đúng thứ tự Một sự kiện có dấu thời gian sau đến trước một sự kiện trước đó Trạng thái "delivered" bị ghi đè trở lại thành "sent"
Lỗi một phần/mơ hồ Trình xử lý của

Tính bất biến: một thuộc tính giải quyết cả ba

Một điểm cuối nhận có tính bất biến tạo ra cùng một trạng thái cuối cùng bất kể sự kiện tương tự được phân phối bao nhiêu lần. Cơ chế này đơn giản và được hiểu rõ: mỗi sự kiện đến mang một ID sự kiện duy nhất; trước khi xử lý, bạn kiểm tra xem bạn đã ghi lại ID đó chưa; nếu có, bạn trả về thành công ngay lập tức mà không xử lý lại. 1.

Thứ tự sự kiện: tại sao "ghi cuối cùng thắng" là nguy hiểm

Các sự kiện webhook cho cùng một tin nhắn không được đảm bảo đến theo thứ tự chúng xảy ra. Một lần thử lại của một sự kiện "queued" trước đó có thể đến sau một sự kiện "delivered" sau đó do độ trễ mạng, xếp hàng ở phía nhà cung cấp, hoặc nhóm worker của chính bạn xử lý các yêu cầu không theo thứ tự.

Cờ đỏ

  • Không có ID sự kiện duy nhất trong payload webhook, hoặc tích hợp của bạn bỏ qua ID hiện có
  • Cập nhật trạng thái được áp dụng bằng cách ghi đè đơn giản mà không so sánh dấu thời gian
  • Xử lý STOP không nằm sau cùng logic khử trùng lặp như tin nhắn đến thông thường
  • Trình xử lý webhook thực hiện các cuộc gọi hạ nguồn đồng bộ (email, CRM, định tuyến nhân viên) trước khi xác nhận
  • Không có nhật ký cho thấy có bao nhiêu ID sự

Bắt đầu với IOSOR

Kéo nhật ký webhook inbound tuần trước và đếm ID sự kiện đến hơn một lần. Phát lại một bản trùng và một cặp lệch thứ tự (failed rồi delivered). Máy nhận giữ một hiệu ứng: một dòng inbox, một ghi STOP, một chạm ví. Last-write-wins đảo STOP là trượt. Đây là idempotency lúc nhận và thứ tự retry, không xác thực chữ ký, không khóa cổng trước hàng đợi.

Điểm chính IOSOR

Webhook inbound retry. Idempotency lúc nhận là câu trả lời an toàn duy nhất; thứ tự không phải lời hứa.

Làm: khóa sự kiện và bỏ bản đôi. Đừng: last-write-wins lên STOP hoặc trừ cùng sự kiện hai lần.

Hướng dẫn này có hữu ích không?

Hướng dẫn liên quan