Webhook vs polling

Webhook vs polling là gì?

Khi sản phẩm của bạn cần biết một việc vừa xảy ra ở hệ thống khác — ngân hàng báo tiền đã về, đơn vị vận chuyển báo đã giao hàng — chỉ có hai cách để tin đó đi tới bạn.

Webhook: bên kia chủ động gọi sang hệ thống của bạn ngay khi có việc. Giống như họ nhắn tin cho bạn.

Polling: hệ thống của bạn hỏi lại bên kia theo chu kỳ — 30 giây, 5 phút, mỗi giờ một lần. Giống như bạn mở app ra kiểm tra liên tục.

Hệ quả quan trọng nhất với BA/PO: nếu luồng đang chạy bằng polling chu kỳ 5 phút, thì "cập nhật ngay lập tức" là điều không tồn tại — không phải vì dev làm ẩu, mà vì cơ chế nó vậy.

Bạn cần hiểu điều gì

• Cập nhật từ bên ngoài đến bằng webhook (họ đẩy) hoặc polling (ta hỏi định kỳ).
• Có những cập nhật không tức thời theo bản chất — đó là thiết kế, không phải lỗi.
• Webhook có thể tới trễ, tới trùng, hoặc không tới; polling luôn có độ trễ tối đa bằng chu kỳ hỏi.

Bạn làm được gì với nó

• Nhìn một luồng và nói được nó chạy bằng cơ chế nào, từ đó phán đoán độ trễ hiện tại là bình thường hay bug thật.
• Spec trạng thái pending cho mọi luồng liên quan tới tiền: người dùng thấy gì trong lúc chờ, chờ tối đa bao lâu, quá hạn thì sao.
• Viết thời gian cập nhật thực tế vào acceptance criteria thay vì chữ "ngay lập tức".

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — "Thanh toán xong rồi mà app 30 giây sau mới hiện"

Tình huống: QA báo bug: chuyển khoản thành công trên app ngân hàng, nhưng đơn hàng 30 giây sau mới đổi sang "Đã thanh toán".

Cách đọc: hỏi dev một câu — "mình nhận kết quả thanh toán bằng webhook hay polling?". Nếu là polling chu kỳ 30 giây, đây không phải bug; 30 giây chính là chu kỳ hỏi.

Học được: độ trễ là thuộc tính của cơ chế. Biết cơ chế là biết độ trễ tối đa mà không cần đọc code.

Trung bình — Viết spec cho chính luồng đó

Tình huống: bạn viết ticket cho màn hình thanh toán.

Việc cần viết ra:

• Sau khi bấm thanh toán, đơn hàng ở trạng thái Đang xác nhận, không phải Thành công.
• Người dùng thấy: "Đang xác nhận thanh toán, thường mất dưới 1 phút."
• Sau 5 phút chưa có kết quả: hiện hướng dẫn liên hệ hỗ trợ, không tự huỷ đơn.
• Acceptance criteria ghi "cập nhật trong vòng 60 giây", không ghi "ngay lập tức".

Học được: cơ chế quyết định số trạng thái màn hình phải có. Bỏ pending state là bỏ luôn 4/5 tình huống thật.

Nâng cao — Webhook của nhà cung cấp không đáng tin

Tình huống: đơn vị vận chuyển có webhook, nhưng thực tế khoảng 2% sự kiện không bao giờ tới, và khi hệ thống họ nghẽn thì cùng một sự kiện gửi lặp 3–4 lần.

Thiết kế đúng: nhận webhook để có tốc độ, đồng thời polling thưa (ví dụ 15 phút/lần) để quét những đơn bị sót — đây gọi là reconciliation.

Phải viết vào spec:

• Mỗi sự kiện có mã định danh riêng; xử lý lần thứ hai trở đi không được đổi trạng thái đơn (idempotency).
• Sự kiện tới sai thứ tự (báo "đã giao" trước "đang giao") thì không được lùi trạng thái.
• Chênh lệch giữa webhook và lần quét đối soát được ghi log để đội vận hành xem.

Học được: "cứ dùng webhook đi" không phải một câu trả lời. Câu trả lời là webhook cộng đối soát, cộng quy tắc chống trùng.

Áp dụng khi viết spec

Với mỗi luồng có dữ liệu đến từ bên ngoài, ticket của bạn phải trả lời được bốn câu:

1. Cập nhật này đến bằng webhook hay polling? Chu kỳ bao lâu?
2. Người dùng thấy gì trong lúc chờ? (đây là trạng thái pending)
3. Chờ tối đa bao lâu thì coi là thất bại, và khi đó hiện gì?
4. Nếu cùng một cập nhật tới hai lần thì hệ thống làm gì?

Câu hỏi nên hỏi dev

• "Luồng này nhận kết quả bằng webhook hay mình chủ động hỏi lại?"
• "Nếu là polling thì chu kỳ bao nhiêu — đó là độ trễ tối đa người dùng thấy đúng không?"
• "Nhà cung cấp có gửi lại khi webhook fail không? Gửi lại mấy lần?"
• "Mình đã chống trùng chưa, hay nhận hai lần là cộng tiền hai lần?"
• "Có cơ chế đối soát để bắt những sự kiện bị mất không?"

Sai lầm thường gặp

• Viết "cập nhật real-time" trong PRD cho một luồng chạy polling 5 phút — cả team pass ticket, người dùng thấy sai.
• Bỏ qua trạng thái pending, chỉ thiết kế màn hình thành công và thất bại.
• Báo bug "app không cập nhật" mà chưa hỏi cơ chế — mất thời gian của cả hai bên.
• Cho rằng webhook là bảo đảm. Webhook là nỗ lực tốt nhất, không phải cam kết.
• Quên rằng nhà cung cấp có thể gửi sự kiện sai thứ tự.

Definition of done — dấu hiệu bạn đã đạt

• Với bất kỳ luồng nào trong khu vực của mình, bạn nói được nó chạy webhook hay polling mà không cần hỏi lại.
• Mọi ticket bạn viết cho luồng bên ngoài đều có trạng thái pending và một mốc thời gian cụ thể.
• Bạn phân biệt được "chậm theo thiết kế" và "bug" trước khi tạo ticket.

Đi sâu hơn

• API (request/response) — đọc tài liệu API và spec integration.
• Cron job — khi độ trễ đến từ lịch chạy thay vì từ cơ chế truyền tin.