"Polling is repeatedly knocking on a door to see if anyone’s home. Webhooks are installing a doorbell that notifies you when someone arrives."

We just published a deep dive comparing webhooks vs. polling — not just the theory, but the tradeoffs teams face when building at scale.

- Polling: simple, reliable, but inefficient and often delayed.

- Webhooks: real-time and resource-friendly, but tricky to secure, monitor, and debug.

Curious to hear from HN: 1. Do you default to webhooks whenever possible? 2. Or is polling still underrated for certain use cases? 3. Any horror stories (or success stories) with either approach?

Webhooks have quietly become the backbone of modern SaaS integrations — Stripe, GitHub, Shopify, Slack… almost every product relies on them.

On the surface, they’re just POST requests. But at scale, teams end up reinventing a lot of the same infrastructure:

- Retry queues and exponential backoff - Dead-letter queues for failed events - Signature validation and replay protection - Monitoring and observability - Customer support when “the webhook didn’t fire”

This got me thinking: are we overdue for Webhook-as-a-Service (WaaS) to be treated as a first-class primitive, the way cloud providers gave us databases, queues, and object storage?

I wrote up a guide exploring what WaaS is, how it works, and why teams are increasingly adopting it.

Curious: 1. Has your team built webhook infra in-house? 2. Do you see WaaS becoming as common as using S3 or RDS instead of rolling your own? 3. Or is webhook delivery “too small” a problem to deserve its own category?

Would love to hear HN’s take.

I've been working on improving developer experience around event-driven integrations lately, and webhooks continue to be one of those deceptively "simple" tools that actually require quite a bit of infrastructure to handle properly at scale—retries, signature validation, queuing, DLQs, observability, etc.

I recently published a technical post that goes deep into what webhooks are, how they actually work under the hood, and why they matter in modern architectures: https://vartiq.com/blog/what-is-webhook-how-it-works-and-why...

Would love to hear how others are handling webhooks in production:

1. How are you queuing/processing them? 2. Do you use a third-party tool? 3. What kind of failure handling/retries do you implement?

Curious what the broader HN community thinks about the evolution of webhooks and whether we're due for better primitives around this.

Lol. But this can be pivoted into something fun and lovely for couples.

A lot to do in this space indeed. A clear blue ocean.

That resonates. Testing asynchronous and multithreaded code for all possible interleavings is notoriously difficult. Even with advanced fuzzers or concurrency testing frameworks, you rarely gain full confidence without painful production learnings.

In distributed systems, it gets worse. For example, when designing webhook delivery infrastructure, you’re not just dealing with async code within your service but also network retries, timeouts, and partial failures across systems. We ran into this when building reliable webhook pipelines; ensuring retries, deduplication, and idempotency under high concurrency became a full engineering problem in itself.

That’s why many teams now offload this to specialized services like Vartiq.com (I’m working here), which handles guaranteed webhook delivery with automatic retries and observability out of the box. It doesn’t eliminate the async testing problem within your own code, but it reduces the blast radius by abstracting away a chunk of operational concurrency complexity.

Totally agree though – async, threading, and distributed concurrency all amplify each other’s risks. Communication and system design caution matter more than any syntax or library choice.

> That’s why many teams now offload this to specialized services like Vartiq.com

It would be nice to add a disclaimer that this is a system you're working on.

Thanks for pointing out. Edited. :)