Polling vs Webhooks: When Should You Use Each?
Compare polling and webhooks — latency, reliability, and reachability trade-offs, plus when to combine both patterns.
Expected Interview Answer
Polling has a client repeatedly ask a server “is there anything new?” on a fixed interval, while a webhook has the server call a URL the client registered in advance the instant an event happens, so polling trades timeliness for simplicity and webhooks trade simplicity for near-instant delivery.
Polling is easy to implement and works behind firewalls or NATs since the client always initiates the connection, but it wastes requests when nothing has changed and introduces latency up to the polling interval. Webhooks eliminate that waste and latency by having the source push an HTTP callback the moment an event occurs, but they require the receiver to expose a publicly reachable endpoint, handle retries and duplicate deliveries, verify request authenticity (e.g., signature headers), and deal with ordering issues if multiple events arrive out of sequence. In practice, teams often pick polling for low-frequency or firewall-restricted integrations and webhooks for high-frequency, latency-sensitive integrations, sometimes combining both by using a webhook to trigger an immediate reconciliation poll as a safety net.
- Polling is simple to implement and works even when the client cannot expose a public endpoint
- Webhooks deliver near-instant notifications without wasted “nothing changed” requests
- Webhooks scale better for high event volume by avoiding constant re-checking
- Combining both gives near-instant delivery with a reliable polling-based safety net
AI Mentor Explanation
Polling is like a fan repeatedly refreshing the scoreboard app every thirty seconds to see if a wicket has fallen, which works fine but wastes checks when nothing has changed and can lag behind the real event. A webhook is like signing up for a push alert so the broadcaster’s system calls your phone the instant a wicket falls, giving near-real-time news without constant checking, but you must keep your phone reachable and handle duplicate alerts if the network retries. Big sports apps often use both: webhooks for instant alerts and periodic polling as a backup if a notification is missed. That is exactly the polling-versus-webhooks trade-off.
Step-by-Step Explanation
Step 1
Assess event frequency and latency needs
High-frequency, latency-sensitive events favor webhooks; infrequent or firewall-restricted checks favor polling.
Step 2
Check network reachability constraints
Webhooks require the receiver to expose a reachable endpoint; polling works even behind NATs or strict firewalls.
Step 3
Design for reliability
Webhooks need retry handling, signature verification, and idempotent processing for duplicate deliveries.
Step 4
Add a reconciliation safety net
Pair webhooks with a periodic poll to catch any events lost due to delivery failures.
What Interviewer Expects
- Correctly identifies which side initiates the call in each pattern
- Names the wasted-request and staleness downsides of polling
- Names the reachability, retry, and idempotency requirements of webhooks
- Suggests a hybrid or reconciliation strategy for reliability
Common Mistakes
- Assuming webhooks never fail or need retries
- Forgetting that webhook receivers must verify request authenticity (signatures)
- Ignoring firewall/NAT constraints that make webhooks impractical for some clients
- Not mentioning idempotent handling for duplicate webhook deliveries
Best Answer (HR Friendly)
“Polling means the client keeps asking the server “anything new?” on a timer, which is simple but can be slow and wasteful. A webhook flips that around: the server calls a URL you registered the instant something happens, so it is much faster, but your system has to be ready to receive that call and handle things like retries or duplicates safely.”
Code Example
const crypto = require("crypto")
const processedEvents = new Set()
app.post("/webhooks/payment", (req, res) => {
const signature = req.headers["x-signature"]
const expected = crypto
.createHmac("sha256", WEBHOOK_SECRET)
.update(req.rawBody)
.digest("hex")
if (signature !== expected) {
return res.sendStatus(401) // reject unverified calls
}
const event = req.body
if (processedEvents.has(event.id)) {
return res.sendStatus(200) // already handled, avoid double-processing
}
processedEvents.add(event.id)
handlePaymentEvent(event)
res.sendStatus(200)
})Follow-up Questions
- How would you verify that a webhook call actually came from the expected source?
- What strategy would you use if a webhook delivery is silently lost?
- Why might a client behind a corporate firewall be forced to use polling instead of webhooks?
- How do you design idempotent webhook handlers to survive duplicate deliveries?
MCQ Practice
1. Which pattern requires the receiver to expose a publicly reachable endpoint?
Webhooks are delivered by the source calling a URL the receiver registered, so that URL must be reachable from the source.
2. What is a common downside of polling compared to webhooks?
Polling repeatedly asks “anything new?” even when nothing changed, wasting requests and lagging by up to the polling interval.
3. Why should webhook handlers be idempotent?
Delivery retries after timeouts or errors can cause the same event to be delivered more than once, so handlers must tolerate duplicates safely.
Flash Cards
Polling? — Client repeatedly asks the server for updates on a fixed interval.
Webhook? — Server calls a pre-registered URL the instant an event occurs.
Main webhook requirement? — A reachable endpoint that verifies authenticity and handles retries/duplicates idempotently.
Common hybrid approach? — Use webhooks for instant delivery plus periodic polling as a reconciliation safety net.