Thiết kế nhận webhook có tính đến gửi lại và trùng lặp

Webhook cho phép hệ thống khác thông báo cho ứng dụng khi có thay đổi. Sự tiện lợi này chuyển một phần trách nhiệm vận hành sang dịch vụ nhận. Trước khi nối vào quy trình nghiệp vụ, hãy xác định phản hồi xác nhận thành công có nghĩa gì và cách khôi phục thông điệp lỗi sau khi nhận.

Bắt đầu từ bảo đảm thực tế của bên gửi

Đọc hợp đồng nhà cung cấp thay vì mặc định mọi webhook giống nhau. Stripe ghi rõ thông điệp có thể được giao trùng và không bảo đảm thứ tự giao sự kiện.[4] Vì vậy, phía nhận của Stripe cần phát hiện trùng và có chiến lược xử lý thứ tự. Bên gửi khác có thể quy định mã nhận diện, thời hạn gửi lại hoặc cách xác nhận khác.

Phân biệt danh tính sự kiện với danh tính nghiệp vụ. Giao lại cùng một sự kiện khác với hai sự kiện cùng liên quan một hóa đơn. Lưu cả hai mã nếu có. Xác định sự kiện đại diện cho thay đổi trong quá khứ hay chỉ thông báo để lấy trạng thái hiện tại.

Tách việc nhận khỏi thực thi nghiệp vụ

Stripe khuyến nghị phản hồi thành công nhanh trước logic phức tạp và yêu cầu nội dung yêu cầu nguyên gốc để kiểm tra chữ ký.[4] Với thiết kế của bạn, trước hết kiểm tra tính xác thực, rồi lưu sự kiện hoặc đưa công việc vào hàng đợi bền vững trước khi xác nhận nhận. Nếu lưu bền vững thất bại, không được báo đã nhận công việc.

Dùng tiến trình xử lý nền để áp dụng thay đổi nghiệp vụ. Nên cập nhật trạng thái nội bộ cùng bản ghi hoàn tất theo danh tính chống trùng trong một thao tác nguyên tử. Tiến trình có thể dừng sau khi gọi hệ thống ngoài, nên tác động phía sau cũng cần cơ chế khôi phục hoặc idempotency. Chỉ có hàng đợi không giải quyết được sự bất định đó.

Đưa phát lại vào năng lực vận hành

Sự kiện lỗi cần nhìn thấy được nhưng không phải ai cũng được xem toàn bộ nội dung. Cho người vận hành có quyền biết nguyên nhân, lịch sử thử và thao tác phát lại có kiểm soát. Xác định khi nào cần lấy trạng thái mới từ nhà cung cấp thay vì lặp chuyển trạng thái cũ.

Ghi nhật ký kiểm toán cho thao tác phát lại. Người vận hành cần biết ai yêu cầu thử thêm, sự kiện nào liên quan và lần phát lại có thể tạo tác động ra hệ thống ngoài hay không. Không cấp quyền phát lại mặc định cho mọi người chỉ vì họ được xem lỗi.

• Kiểm tra chữ ký bên gửi theo quy trình được nhà cung cấp mô tả.
• Lưu nhà cung cấp, mã sự kiện, thời điểm nhận và trạng thái xử lý.
• Kiểm thử sự kiện trùng, đến muộn, đảo thứ tự và đến đồng thời.
• Đưa lỗi đã hết lượt thử vào hàng đợi xem xét có người phụ trách.

Ví dụ giả định: quyền truy cập theo thuê bao

Ví dụ giả định: nền tảng học tập nhận sự kiện đổi thuê bao trước sự kiện tạo thuê bao trước đó. Tiến trình nền lấy trạng thái thuê bao hiện tại rồi cập nhật quyền truy cập theo trạng thái ấy, thay vì tin thứ tự đến. Sự kiện lặp không tạo thêm quyền.

Cách này cần gọi thêm nhà cung cấp và có thể gặp lúc dịch vụ bên đó ngừng hoạt động. Nền tảng giữ sự kiện ở trạng thái chờ và hiển thị độ trễ cho bộ phận hỗ trợ. Với quy trình phải giữ từng chuyển trạng thái trong quá khứ, chỉ lấy trạng thái hiện tại là không đủ. Hãy chốt khác biệt này trước khi triển khai, rồi trình diễn cách khôi phục khi tiến trình dừng giữa lúc cập nhật quyền truy cập.