Polling vs Webhooks: System Design Trade-offs

Side by side

Dimension	Polling	Webhooks
Who initiates	Consumer requests updates	Producer sends HTTP callbacks
Detection latency	Depends on polling interval	Depends on dispatch and receiver backlog
Request volume	Requests even when nothing changes	Driven by events, subscriptions, and retries
Consumer reachability	Only outbound access needed	Producer must reach a callback endpoint
Load control	Consumer controls request cadence	Producer needs per-endpoint delivery limits
Outage recovery	Resume from durable cursor if supported	Retry, replay, or reconcile missed updates
Correctness risks	Skipped changes or repeated reads	Duplicate, delayed, or reordered callbacks
Security	Authenticate and authorize API requests	Also verify signatures and constrain callback URLs

The differences that matter

Polling trades freshness for request volume. With N consumers each making one request every T seconds, baseline traffic is approximately N/T requests per second, before pagination and retries. If changes arrive uniformly between successful polls, average detection delay is about T/2. Conditional requests can reduce response bytes, but they do not eliminate requests.

Webhooks avoid empty checks but introduce a delivery pipeline. Persist events durably, queue deliveries, isolate slow subscribers, and retry transient failures with exponential backoff and jitter. A transactional outbox can close the gap between committing a business change and recording its notification. Bursts and fan-out still require capacity planning.

Neither approach guarantees complete, exactly-once processing. Polling a current-state endpoint can miss intermediate transitions; a retained change feed with a durable cursor can preserve them. Webhook retries can produce duplicates, and concurrent deliveries can arrive out of order. Use event IDs, idempotent processing, and resource versions where ordering matters.

The network boundary changes the operational burden. Polling works when the consumer cannot accept inbound connections. Webhooks require a reachable endpoint, authenticated payloads, replay protection, and safe callback URL handling to prevent server-side request forgery. Acknowledge only after durable acceptance, then process asynchronously; use replay or reconciliation after retry retention expires.

Choose Polling when

The provider exposes only a read API, or the consumer cannot host an endpoint reachable by the provider.
Updates are infrequent, the number of consumers is small, and a delay of minutes is acceptable.
The consumer must control its intake rate and the API offers retained changes with stable cursors.
You need periodic reconciliation of authoritative state, including after webhook delivery failures.

Choose Webhooks when

Server-to-server consumers need prompt notification without repeatedly checking unchanged resources.
Many consumers would otherwise generate substantial empty polling traffic.
Individual state transitions matter and the producer can durably record and deliver event notifications.
You can operate authenticated callback endpoints, durable intake queues, retries, and idempotent handlers.

A worked example

Payment status updates for merchant integrations

Suppose 20,000 merchant integrations each check for changed payments every 30 seconds. That creates about 667 requests per second before pagination or retries, even during quiet periods. Under uniformly timed changes and healthy requests, average detection delay is about 15 seconds. If the producer instead emits 100 payment events per second, with one subscribed merchant per event, webhooks start at roughly 100 delivery attempts per second before retries. Choose webhooks for prompt notification, persist events through an outbox, and require idempotent merchant handlers. Keep a cursor-based changes API for recovery. A merchant offline beyond the replay window must reconcile payment state rather than assume every callback will eventually arrive.

In the interview

Start with the freshness target and network boundary. Ask whether this is a server integration or a browser update path; webhooks are not a direct substitute for WebSockets or server-sent events.
Estimate polling traffic with N/T, then estimate webhook deliveries from event rate multiplied by matching subscriptions. Include retries, pagination, and burst traffic rather than comparing only averages.
Explain both recovery paths. The interviewer may ask what happens if a consumer is offline longer than event retention, a cursor expires, or a callback is permanently rejected.
Trace an ambiguous outcome: the receiver commits an event but its response is lost. Show how a retried delivery avoids a second business effect, using an event ID recorded atomically with the local update.
Offer a hybrid when correctness matters: webhooks trigger prompt work, while a retained change feed or periodic state reconciliation repairs gaps. Explain whether the requirement is current-state convergence or processing every transition.

Common mistakes

Calling webhooks guaranteed real-time or exactly-once. Queues, outages, retries, and receiver failures can delay or duplicate delivery.
Claiming polling cannot miss events. Repeated snapshots may skip intermediate states, and pagination without stable cursor semantics can skip records.
Returning success before a webhook is durably accepted, or performing slow business logic before acknowledging it.
Ignoring synchronized polling spikes and webhook retry storms. Add jitter, bounded concurrency, backoff, and per-consumer isolation.

Where it comes up

Interview questions where choosing between Polling and Webhooks comes up.

Questions people ask

Are webhooks better than polling?

Webhooks are often better for prompt server-to-server notifications when polling would mostly return no changes. Polling is simpler when updates can wait, inbound connectivity is unavailable, or the provider lacks callbacks. The right choice depends on freshness, traffic, and recovery requirements.

Can webhooks replace polling completely?

Only if their delivery and recovery mechanisms cover the application's requirements. Retry windows are finite, so consumers often still need a replay API or periodic reconciliation. Recovering current state is not the same as recovering every missed transition.

What is the difference between long polling and webhooks?

With long polling, the consumer opens a request that the server holds until an update arrives or a timeout occurs. With webhooks, the producer opens a separate request to the consumer's callback endpoint. Long polling reduces empty responses compared with short polling, but requires managing waiting requests and reconnects.