When evaluating whether to use webhooks or polling for an architectural decision I've been reading some articles. Most highlight the obvious drawbacks with using polling such as:

  • wasted resources (most polls don't return an update)
  • added latency (due to polling timeout)

So most recommendations burn down to "use webhooks instead of polling". Putting my skeptic hat on though I can't help but wonder if there are downsides and alternative scenarios. So my question is - what are the examples of scenarios where use of polling would be preferable to webhooks?

  • 2
    Probably best you should focus on some scenarios and use cases you need to solve? – πάντα ῥεῖ Jan 26 '20 at 14:17
  • 2
    Polling is preferable when you only control one side of the service and webhooks aren't available on the other side. Then it's polling or nothing unless you can somehow convince the developers of the other service that webhooks would be helpful for them. – CJ Dennis Jan 27 '20 at 8:19

In most cases web hook is superior to polling. The only aspect that polling is unarguably better than webhook is that polling is usable when the client is behind a NAT and therefore can't make a listening port to receive a webhook.

One case when web hook doesn't bring any advantage, but a polling architecture is signficantly simpler to implement, is when you want to buffer multiple updates and need to have a scheduled update windows, or when the update rate is higher than your ability to respond to the update. In this case, there's no reason to receive updates outside the update window anyway, so polling works just as well as web hook as you can batch multiple updates together, while the infrastructure to implement webhook would be much more complex because the system would have to have separate Cron job to run on scheduled window and a data storage to buffer the updated data between update windows.


Prefer Both.

Why? Because neither is guaranteed to work.

You want to have a webhook setup because it minimises the time to notification, and reduces network load. Don't pester someone, let them tell you when its ready.

Except sometimes the someone forgets to get back to you. So you do want to pester them periodically. Which is why you also want polling. Albeit you want polling to be on a much slower schedule, unless you've determined the webhook isn't being respected/delivered on, in which case you want to step it up.

Generally I set the polling behaviour to something tolerable, but infrequent in some cases this is 10 secs, other times 24hours. If the webhook is predictable in that its reporting back on a schedule (like a heartbeat) then use a multiple of the the length of the longest period of silence expected. This gives the sending system a buffer for a slow network, or a couple of notification failures before your system start polling it. Reset the polling countdown for every successful webhook received and poll conducted. Have a larger countdown for monitoring if webhooks are coming in at all (when they are expected on a schedule) and reset it on a successfully received webhook. Should this timer go off it can setup polling to occur more frequently. If enough webhooks come through before a poll is conducted then polling can be made less frequent.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.