Webhooks

HTTP callbacks where a system POSTs events to your URL when something happens, instead of you polling. They're the cheapest way to get real-time-ish updates from third parties. Reliability depends on retries and idempotency.

When to use

Third-party event integrations (payments, CI, forms).
Avoiding polling for infrequent events.

When not to

High-frequency low-latency streams (use streaming/WebSockets).
Consumers behind firewalls with no public endpoint.

Definition

A webhook is an HTTP POST the producer sends to a registered consumer URL on an event. The consumer must acknowledge quickly and handle duplicates. Often signed (HMAC) so the consumer can verify authenticity.

Why it exists

Polling is wasteful and laggy. Webhooks push events when they happen with no consumer polling infrastructure, ideal for integrations where you can expose an HTTP endpoint.

How it works

Consumer registers a URL. On event, producer POSTs a payload (often with a signature header). Consumer returns 2xx fast and processes async; non-2xx triggers retries with backoff. Idempotency keys dedupe retries.

Scaling limits

Consumers must be reachable and fast; a slow consumer gets backed off or dropped. Ordering across webhooks isn't guaranteed. Fan-out to many endpoints scales the producer's outbound.

Cost shape

Cheap for the producer (one outbound POST). Cost is reliability infra: retries, dead-letter queues, signature verification, and replay handling.

Alternatives

Polling — Simpler, no inbound endpoint, but laggy and wasteful.
Streaming/SSE — Continuous push over one connection, but needs a live client.

Failure modes

Consumer can't keep up, causing retry storms.
Unsigned webhooks spoofed by attackers.
Out-of-order or duplicate delivery breaking non-idempotent handlers.

Idempotency, SQS, Kafka, Server-Sent Events (SSE), Dead-letter queue (DLQ)