Somewhere in almost every SaaS product there is a loop that does nothing but ask a question over and over: anything new yet? A job runs every minute, hits an API or a database, compares the result to what it saw last time, and — most of the time — finds that the answer is no. This is polling, and it is one of those patterns that feels harmless because each individual call is cheap. The cost only shows up when you add up the ones that returned nothing.

What polling actually costs

Polling has two hidden bills. The first is waste. If you check every 30 seconds for an event that happens twice a day, you are making roughly 2,880 requests to catch two things. The other 2,878 are pure overhead — network, CPU, database reads, rate-limit budget, log noise — spent confirming that nothing happened. Multiply that across every integration and every customer and the waste stops being trivial.

The second bill is latency, and it is the one your users feel. A polling interval is a deliberate delay. If you poll once a minute, then on average you learn about an event 30 seconds after it happened, and in the worst case a full minute later. You can shrink the interval to feel more real-time, but every second you shave off multiplies the waste from the first bill. Polling forces you to choose between “fast” and “cheap,” and you never quite get either.

There is a third, quieter cost: complexity. Polling code has to track cursors, de-duplicate, and handle overlapping runs. None of that logic is your product — it is scaffolding you maintain forever so one system can find out what another already knew.

The alternative: be told, don’t ask

The inversion is simple to state. Instead of the consumer repeatedly asking “did anything change?”, the producer says “this changed” at the exact moment it does. That is a webhook — an outbound HTTP call the platform makes to you when something worth knowing happens. No interval to tune, no empty checks, no cursor bookkeeping. The event arrives once, promptly, carrying the data you needed.

Push is not magically free — the work moves rather than vanishing — but it moves to where it belongs. The system that owns the state change already knows the moment it occurs, so it is the cheapest possible place to announce it. Everyone downstream stops guessing.

The honest caveat: webhooks introduce their own concerns. Deliveries fail, endpoints go down, and a naive implementation can either lose events or let a broken subscriber take down the thing emitting them. So the real question isn’t “webhooks or polling?” — it’s whether your platform’s push mechanism is reliable under failure. That is exactly where hand-rolled webhook code falls apart.

How VBWD does push without the fragility

VBWD is event-driven at its core: every meaningful state change — a subscription activating, a payment captured, stock moving — is published to an in-process event bus. A single agnostic relay turns any published event into a signed outbound webhook. The part that matters for reliability is the split between enqueue and deliver.

Enqueue is synchronous and fast: when an event fires, the platform writes a pending delivery row and returns. It does not make the HTTP call inline. A background scheduler picks up pending deliveries out of band (roughly every 25 seconds) and performs the POST. The consequence is the important bit: a webhook failure never breaks event emission. Your subscription still activates even if the receiving endpoint is on fire.

Failed deliveries retry with capped exponential backoff — base 30 seconds, cap six hours, up to five attempts — and every attempt is persisted with its status, response and error, so you can see exactly what happened. After five consecutive failures a subscription auto-disables and is surfaced as failed, rather than hammering a dead endpoint forever.

Each delivery is signed with HMAC-SHA256 over the exact JSON body using a per-subscription secret, and arrives with headers you verify against:

X-VBWD-Signature:   sha256=<hmac of raw body>
X-VBWD-Event:       payment.captured
X-VBWD-Delivery-Id: 6f2a...
X-VBWD-Timestamp:   1754...

Your side recomputes the HMAC over the raw body and does a constant-time compare — so a receiver can trust that the payload is genuine and untampered, without polling anything to confirm it.

Subscriptions can be surgical (["payment.captured"]) or a firehose (["*"]), and because the relay delivers whatever is published, events from plugins — subscription, shop, booking, dataset, marketplace — reach a wildcard subscriber automatically. “Notify my system when X happens” becomes a row in /admin/webhooks, not a sprint. And because VBWD is self-hosted and source-available, the bus, the delivery queue and the signing secrets all live inside your own perimeter.

If you want the full mechanics — how the event bus, the agnostic relay and the delivery scheduler fit together — the engineering write-up is worth reading: Webhooks in VBWD, Part 1: the event-driven engine.

Polling asks the same question thousands of times to catch one answer. Push answers once, immediately, signed. The difference isn’t just efficiency — it is a platform that tells you what happened instead of making you go find out.

If this maps to a conversation happening inside your own organisation, the useful next step is specific rather than generic: see your own workload on modern, self-hosted infrastructure. Request an enterprise installation and bring the numbers you’re trying to improve.