proto.lib

Inbound Webhook Ingestion (nhận webhook từ bên thứ ba)

Khi là bên nhận webhook, endpoint phải xác thực chữ ký, trả 2xx NGAY trước khi xử lý bằng cách ghi payload gốc vào một queue bền vững, rồi xử lý bất đồng bộ với dedup theo event id của nhà cung cấp — vì bất cứ độ chậm hay lỗi nào cũng khiến bên gửi retry, gây trùng lặp và cuối cùng vô hiệu hoá endpoint.

MessagingTrung bình2026-08-25
Inbound Webhook Ingestion (nhận webhook từ bên thứ ba)

Tags

#webhook#ingestion#idempotency#queue#signature-verification#replay#durability

Tài liệu tham khảo

Mở rộng

Animation gốc là một file HTML tự chứa, có thể nhúng lại ở bất kỳ trang nào khác. Mở file gốc

Liên quan

MessagingTrung bình

Webhook Fan-out: cách ly từng Subscriber

Khi một broker phải giao một sự kiện tới hàng trăm endpoint khách hàng có độ tin cậy rất khác nhau, mỗi subscriber cần hàng đợi/trạng thái riêng (retry schedule, circuit breaker, backlog riêng) để một endpoint bị treo cả ngày không làm chậm việc giao hàng cho các subscriber khác.

#webhook#fanout#subscriber-isolation#circuit-breaker
MessagingTrung bình

Pub/Sub: Push vs Pull Subscription

Với pull subscription, consumer tự gọi API để lấy message và tự kiểm soát tốc độ; với push subscription, broker chủ động POST message tới endpoint của bạn và tự backoff khi nhận response không phải 2xx — điều này chuyển quyền flow control từ consumer sang broker và biến độ khả dụng của endpoint thành một phần của đường truyền tải.

#pubsub#push-subscription#pull-subscription#flow-control
MessagingTrung bình

Sink Connector ghi idempotent bằng upsert

Một sink kết nối stream vào database phải tránh trùng lặp khi redelivery: nó tính khoá xác định cho mỗi record và ghi bằng upsert (hoặc insert kèm unique constraint), đồng thời lưu version/offset của record để một retry cũ hơn không thể ghi đè bản mới hơn.

#sink-connector#idempotency#upsert#at-least-once