Problem
Polling wastes resources and adds latency. Consumers need immediate notification of events.
distribution-communicationestablished · medium operational burden
Webhook
Also known as: http://a.does-not-exist.example.com/started callbacks
Intent
Enable real-time server-to-server notifications via HTTP callbacks, avoiding polling.
Forces
- •Event producers don't know all consumers at design time
- •Consumers need real-time updates
- •HTTP is universal; no special client library needed
- •Delivery must be reliable (retries, ordering)
Solution
✓ When to Use
- •Third-party integrations (Stripe, GitHub, Slack)
- •Cross-organization event notification
- •Consumer-controlled endpoints
✗ When Not to Use
- •High-throughput internal services (use message broker)
- •Consumer can't receive HTTP (firewall, no public endpoint)
- •Strict ordering required (broker better)
Pros
- +Simple: HTTP POST, no special protocol
- +Consumer-controlled: own URL, own stack
- +Real-time: no polling latency
- +Universal: any language, any platform
Cons
- −Reliability: consumer downtime = missed events
- −Security: HMAC verification, replay attacks
- −Operational: retry queues, DLQ, monitoring
- −Scalability: producer fans out to many URLs
Cost Profile
Infrastructure
Low — HTTP endpoint, retry queue
Operational
Medium — delivery monitoring, DLQ handling
Cognitive
Low — familiar HTTP pattern
Failure Modes
Consumer down → events queue, retry storm on recovery
Slow consumer → producer thread pool exhausted
Signature mismatch → legitimate events rejected
No idempotency → duplicate processing
DLQ overflow → events lost permanently
Real-World Examples
Alternatives
- message-broker
- polling
- server-sent-events
- websocket
- grpc-streaming
Related Patterns
- idempotency-key
- outbox-pattern
- retry-with-backoff
- dead-letter-queue
- webhook-security
Competency Domains
distribution communicationreliability opssecurity complianceeconomics evolution