We Revisited a Webhook vs Polling Decision Two Years Later, Were We Right

Two years ago, building a sync between a client's e-commerce platform and their data warehouse, we chose scheduled polling over webhooks, which felt contrarian at the time — webhooks were the obvious 'modern' choice and most blog posts treated polling as the thing you do when you can't do better. I wanted to go back and actually check whether that call held up, instead of assuming it did just because nothing had caught fire.

Why we picked polling in the first place

The vendor's webhook implementation, at the time, had no delivery guarantees, no retry mechanism on failure, and no way to detect a dropped event short of comparing against a periodic full reconciliation anyway. If we were going to need reconciliation logic regardless, the webhook layer was adding complexity — signature verification, endpoint uptime requirements, replay handling — without removing the one thing reconciliation exists to catch. Polling every fifteen minutes against a reliable list endpoint, with a 'last modified since' cursor, got us the same practical freshness with far less moving infrastructure.

Webhooks promise real-time. Polling promises a number you can actually audit. Two years in, the audit trail turned out to matter more than the fifteen minutes of latency.

What the two-year check actually found

Pulling incident history and latency data from the last two years, the polling approach had zero data-loss incidents, versus a hypothetical webhook approach we modeled against the vendor's now-public webhook failure-rate stats, which implied we'd have hit silent delivery gaps requiring reconciliation anyway roughly every six weeks. The fifteen-minute staleness never once showed up as a real business complaint — nobody downstream needed sub-fifteen-minute freshness for warehouse reporting.

• Infrastructure cost: polling needed a scheduler and a simple cursor table. A webhook approach would have needed a public endpoint, signature verification, a dead-letter queue, and reconciliation anyway — net more code to maintain, not less.
• Vendor's webhook reliability actually improved over two years, which is worth re-checking periodically, but the gap-detection and retry logic we'd still need didn't go away even with their improvements.
• The one place polling genuinely cost us: a feature request for near-real-time inventory alerts, which polling couldn't satisfy, and which we ended up solving with a narrow, separate webhook integration just for that one event type.

The verdict: the original call was right for the system as a whole, but not universally right forever — we ended up with a hybrid, polling for the bulk sync and a single purpose-built webhook for the one use case that actually needed low latency. The real lesson from revisiting it wasn't vindication. It was that 'polling vs webhooks' was never a single decision to get right once — it's a tradeoff worth re-checking against actual incident data, not nostalgia for the reasoning that made sense two years ago.