Push or pull
When service A needs to learn about events in service B, there are two shapes.
- Polling has A repeatedly ask B for new data. It is simple and A stays in control, but most polls return nothing, wasting requests, and updates lag by the poll interval.
- Webhooks flip the direction: A registers a URL, and B sends an HTTP request to it whenever an event happens. Updates are near instant and there are no wasted calls.
The catch with webhooks
Pushing creates reliability and security duties on the receiver:
- The receiver must be publicly reachable and respond fast, doing real work asynchronously.
- Deliveries can fail, so the sender must retry, which means the receiver must be idempotent to tolerate duplicates.
- The receiver must verify the signature so attackers cannot forge events.
Polling avoids these by keeping control on the consumer side, at the cost of latency and waste. A common hybrid is webhooks to notify plus a poll or fetch to reconcile anything missed.
Key idea
Webhooks push events for low latency but demand retries idempotency and signature checks while polling pulls simply at the cost of latency and waste.