Polling vs. Webhooks: When to Switch, and the Reliability Traps Waiting on the Other Side
A backend job runs every sixty seconds, checking a payment provider, a CRM, or an inventory system for anything new since the last check. It worked fine when the product had a handful of customers. Now there are thousands of accounts being polled on that same cycle, the API calls are eating into rate limits shared with actual user-facing features, the sixty-second delay is starting to show up in support tickets ("why did it take a minute for my order status to update?"), and the hosting bill for a job that's mostly checking "nothing changed" over and over keeps climbing. This is the moment most teams start looking at webhooks, and it's usually the right instinct. But webhooks are not automatically more reliable than polling, they're differently unreliable, and switching without addressing that trades one set of problems for another that's often harder to detect.
Why polling stops working as a product grows
Polling has real advantages early on: it's simple, it's fully within your control, and there's nothing to configure on the sending side. But it degrades in predictable ways as scale increases:
The cost scales with check frequency, not with actual event frequency. Whether or not anything changed, the poll still runs, still costs a request, and still potentially counts against a shared rate limit. A system polling 10,000 accounts every minute makes 14.4 million requests a day even on a day where almost nothing happened.
Latency is a structural tradeoff, not a bug to fix. Polling every sixty seconds means up to sixty seconds of delay by design. Polling more frequently to reduce that delay multiplies the request volume and cost proportionally, and eventually runs into the third party's own rate limits.
Rate limits become a shared resource problem. As polling volume grows, it competes with real-time, user-triggered API calls against the same limit, meaning a batch job checking for updates can degrade the responsiveness of an actual user action happening at the same moment.
It doesn't scale linearly with customer count. Polling infrastructure that works fine at 100 customers often needs a real architectural rework at 10,000, not just more compute thrown at the same job, because the request volume grows linearly with account count regardless of how quiet those accounts actually are.
The general rule of thumb: if update latency matters to users (order status, payment confirmation, inventory sync), if the third party supports webhooks at all, and if polling volume is becoming a meaningful cost or rate-limit constraint, it's time to move. If updates are rare, latency doesn't matter, or the third party's webhook support is unreliable or nonexistent, polling can remain the right choice indefinitely — the switch isn't obligatory just because webhooks are more modern.
Where webhook systems actually go wrong
This is the part that gets skipped when teams move fast to solve the polling cost problem, and it's where most of the real production incidents in event-driven systems come from.
Missed events with no way to know they're missing. Polling is self-healing by nature — even if a check fails, the next one catches up. Webhooks have no equivalent unless it's built in. If a webhook endpoint is down for five minutes during a deploy, or a request times out, or a firewall rule blocks the sender temporarily, those events are simply gone unless the sender retries and the system has a way to detect the gap.
Duplicate events processed as if they were new. Every major webhook provider retries delivery if it doesn't receive a fast enough acknowledgment, which means the same event can legitimately arrive twice, sometimes more. A handler that isn't idempotent will process a duplicate "payment succeeded" event as if it were a second payment, potentially double-fulfilling an order or double-crediting an account.
Out-of-order delivery. Webhooks are not guaranteed to arrive in the order the events occurred. A "subscription cancelled" event can arrive before a "subscription created" event that fired moments earlier, and a handler that assumes strict ordering will end up in a state that doesn't match reality.
Slow handlers causing the sender to give up or retry unnecessarily. Most webhook senders expect an acknowledgment within a short window (often 5-15 seconds) and will treat a slow response as a failure, triggering a retry, even though the handler was still working. This is a common, sneaky cause of the duplicate-processing problem above.
No dead-letter handling for events that fail processing. If a webhook handler throws an exception partway through, or a downstream dependency is briefly unavailable, that event needs to go somewhere for retry or manual review, not just vanish from the logs. Without this, failures are silent until a customer notices something didn't happen.
Signature verification skipped or done incorrectly. Webhook endpoints are public URLs by nature. Without verifying the sender's signature (HMAC, typically), anyone who finds the endpoint can send fake events, which is a real security exposure for anything triggering financial or state-changing actions.
What a properly built webhook system actually needs
- Fast acknowledgment, async processing. The webhook handler's job is to validate the signature, persist the raw event, and return 200 immediately. Actual processing happens in a separate queued job, decoupled from the sender's timeout window.
- Idempotency keys on every event, using the provider's event ID to detect and skip duplicates before they cause a duplicate side effect.
- A persisted event log, so every incoming event is stored before processing, independent of whether processing succeeds — this is what makes replay possible after a bug or outage.
- A dead-letter queue for events that fail processing after retries, with alerting so failures get human attention instead of silently disappearing.
- Reconciliation as a safety net, not a replacement. Even a well-built webhook system benefits from a low-frequency polling job (hourly or daily, not every-minute) that checks for drift between local state and the source of truth, catching the rare missed event that slips through everything else.
- Signature verification on every incoming request, rejecting anything that doesn't validate before it touches any business logic.
- Monitoring on event lag and failure rate, distinct from general uptime monitoring, since a webhook endpoint can return 200 while the async processing behind it is silently failing.
Making the switch without the outage
The actual migration usually goes best run in parallel for a period: keep polling running at a reduced frequency as the safety net while webhooks take over as the primary path, then step polling down to a pure reconciliation job once webhook reliability is proven in production. Cutting over all at once, with no fallback, is how a missed-event edge case turns into a customer-facing incident in week one.
This is the core of what Webhooks & Event-Driven Architecture covers: designing the idempotency, retry, and dead-letter handling around a webhook system properly from the start, and building the migration path off polling without a reliability regression in the process. If the events in question also need to trigger outbound notifications, the same reliability discipline applies on that side too — see why transactional emails land in spam for what happens when a webhook-triggered email system isn't built carefully, since duplicate events are a common, under-diagnosed cause of duplicate transactional emails.
A quick check before calling a webhook migration done
- Does the handler acknowledge fast and process async, or does business logic run inline before responding?
- Is every event deduplicated using the provider's event ID?
- Are failed events retried and eventually routed to a dead-letter queue, or do they just disappear from logs?
- Is there a reconciliation job catching drift, even at low frequency?
- Is the endpoint verifying signatures on every request?
If any of these are missing, the system has traded a slow, expensive, but self-healing polling setup for a fast, cheap system that quietly loses or duplicates data — which is a worse trade than the one it was meant to fix.