Dedicated Issue — Sponsored by Svix

There's an asymmetry in most data platforms I look at. The interior is event-driven — CDC feeds, streams, change feeds, triggers. The perimeter — SaaS sources, partner integrations, the notifications you send your own customers — still runs on polling loops and hand-rolled webhook senders that page somebody at 3 a.m. Today's issue is about that asymmetry: why it exists, what it actually costs, and why multi-step agent systems are about to make it much more expensive. Svix sponsored this issue, and they show up at the end, where they belong in the argument.

Every polling loop is a bet that nothing happened — and most of the time, you win the bet, which is exactly the problem. The request still costs you: quota against someone's rate limit, compute on both ends, and a log line nobody reads. Meanwhile the interval sets your latency floor. Poll every five minutes and your average detection delay is two and a half minutes; worst case is the full five. Tighten the interval and you don't eliminate the trade, you just move it — more empty calls, more rate-limit pressure, more cost.

Then there's the part everyone in this audience has personally debugged: delta windows. Track a cursor or an updated_at watermark, overlap the window to be safe, dedupe downstream, and hope that clock skew and late-arriving updates don't slip a record between polls. When a row goes missing from a synced dataset, the postmortem almost always ends at the seam between two polling windows.

The cloud providers already taught this lesson at the storage layer. Nobody lists an S3 bucket in a loop to detect new objects — you wire up event notifications. Nobody schedules a Logic Apps recurrence trigger when Event Grid will tell you the moment something changes. The platforms moved their own primitives to push years ago, because pull couldn't meet latency or cost targets at scale.

We stopped diffing tables in batch and started tailing logs. DynamoDB Streams, the Cosmos DB change feed, SQL Server CDC, Postgres logical decoding — every serious database now exposes its changes as a stream, because the alternative was rereading the world on a schedule. I mentioned this Monday in the weekly email.

Kinesis and Event Hubs became the spine; EventBridge and Event Grid became the switchboard. AWS describes event-driven architectures as decoupled services communicating asynchronously through events, while Microsoft positions Event Grid specifically around push delivery to subscribers.

Which makes the perimeter strange. The same platforms that move internal changes as events still poll their SaaS sources, still notify partners with a cron job, and — if they expose data products — still make their own customers poll them. The interior modernized. The edges are running the architecture we abandoned inside.

And when a team finally decides to fix an edge — to push instead of being polled — the default move is to build the sender in-house. Which is where the real cost hides.

Every homegrown webhook system begins with the same sentence: "it's just an HTTP POST." And it is — for about a week. Then an endpoint starts timing out, and you need retries. Retries need exponential backoff and jitter, or you've built a DDoS cannon aimed at your own customers. Some deliveries will never succeed, so you need dead-lettering and a way to replay. Duplicate deliveries will happen, so consumers need idempotency keys. Someone will ask whether events arrive in order, and you'll discover that's a genuinely hard promise to make.

Then security shows up. Unsigned webhooks are forged-event vectors, so you sign payloads; signing keys leak, so you rotate secrets; signatures without timestamps invite replay attacks; and endpoint URLs supplied by customers are an SSRF surface pointed at your own network. None of this is optional, and none of it is your product.

The part that finally breaks teams isn't build cost — it's steady state. A slow consumer back-pressures the fleet at 2 a.m. A customer's endpoint flaps and your engineer gets paged for their misconfigured TLS. There's a reason so many teams describe their webhook system with the word "nightmare": the failure modes live on infrastructure you don't control, and without customer-facing logs and a replay button, every failure routes through your support queue and lands on your on-call.

This is a category error database people should recognize immediately. The first SQL query is easy too. That has never meant operating a production database is easy. Writing the callback is not the expensive part. Owning everything that has to happen when the callback fails is.

A mature internal implementation needs some combination of:

That is not a hypothetical list. It is the operational inventory mature webhook products themselves have to address. Svix documents retries, idempotency, security, observability, and customer-facing management and replay among the problems its service handles.

This is the same decision senior infrastructure teams make all the time. Can you run PostgreSQL yourself? Of course. Can you operate Kafka yourself? Certainly. The question is not whether your engineers are capable. It is whether owning that subsystem creates differentiated value. Every component you own acquires a lifecycle. It needs upgrades, security reviews, and eventually, someone gets paged for it. If webhooks are central IP, that trade may make sense. If they are a delivery mechanism attached to your actual product, the economics are different.

Svix keeps a line-item version of this argument in their build-vs-buy matrix, if you want to score your own system.

Agent systems make the polling tax compound. A multi-step workflow is a chain of asynchronous handoffs — Agent A → tool → Agent B → external service → Agent C → final action — where each hop has to learn that the previous one finished. A step might return in 200 milliseconds or 20 minutes.

Do that by polling and the arithmetic is unforgiving. Illustrative model: if completion times are distributed randomly relative to the polling schedule, expected discovery delay is about half the polling interval. So at a 10-second interval, each hop waits ~5 seconds on average for work that's already done. Across four sequential handoffs, that's ~20 seconds of expected coordination latency. Not inference. Not database work. Twenty seconds spent finding out that work which had already finished was finished.

Change the interval to 30 seconds and the same model gives you roughly a minute across four hops. Tighten to 20 seconds across six hops and you get a minute of dead air at the mean, and the tails stack — one slow poll anywhere drags the p95 of the whole workflow.

The exact number in a real system depends on scheduling, workload duration, jitter, and parallelism. The point is that polling latency composes. As agentic applications become more asynchronous, push starts to matter for the same reason queues and event buses matter elsewhere.

This is why the AI infrastructure layer has already gone this way — async model APIs notify on completion rather than making clients poll, and the emerging standard for doing that securely, Standard Webhooks, came out of the webhooks world and has been adopted by providers including Anthropic, OpenAI, and Google Gemini. And the moment agent handoffs cross organizational boundaries, you inherit the full trust problem: the receiver needs to verify who sent the event; the sender needs retries and replay. That is precisely production webhook infrastructure.

This is the category Svix exists for. It's webhooks as a service: Dispatch for sending webhooks to your customers, Ingest for receiving third-party webhooks, and an embeddable App Portal so your customers manage endpoints, inspect deliveries, and hit replay themselves instead of filing tickets. The entire iceberg from earlier — retries with backoff, endpoint health monitoring and auto-disable, signed payloads with secret rotation, replay and SSRF protections, fanout, throttling, multi-tenant isolation — is the product, not your roadmap.

Two details matter for this readership in particular.

First, endpoints aren't limited to HTTP. Current advanced destinations include Amazon EventBridge, SNS, SQS, Snowflake, BigQuery, ClickHouse, Redshift, and object storage: Amazon S3, Google Cloud Storage, and Azure Blob Storage. That means the external boundary does not have to become a separate architectural island. For AWS: SaaS event → Svix → EventBridge → internal consumers. Or: application event → Svix → S3 → downstream data pipeline. The EventBridge integration sends events directly into an event bus per Svix docs. For Azure-heavy orgs, landing events in Blob Storage makes sense when the eventual destination is a data pipeline rather than an HTTP app. The objective is not webhook maximalism. It is to move an event into the delivery mechanism appropriate to the next boundary.

Second, the compliance posture. Svix documents multi-region deployment for data residency, SOC 2 Type II, HIPAA, and PCI-DSS compliance. The core server is open source under the MIT license and can be self-hosted, while Svix also offers the managed service. That matters because "buy" does not have to mean "accept a completely opaque black box."

A useful AI example, with vendor caveat: Replicate runs AI models in the cloud, where inference jobs are naturally asynchronous. In a Svix-published case study, Replicate describes workflows where a job is submitted, a webhook reports completion, the next operation starts, and another webhook announces the next state transition. Replicate had originally built its own sender, encountered observability and noisy-neighbor issues, then migrated the delivery layer to Svix. The case study reports roughly two weeks from decision to production, with much of that spent on verification. That is a vendor-published story, not an independent benchmark, but the architectural pattern is legitimate: if the downstream app has to poll to learn inference is complete, the polling interval becomes part of end-to-end latency.

Other teams running this in production include companies like Brex, Benchling, and Rubrik.

If your team is hand-rolling this — or about to — look at what you could stop building. Free tier, no credit card required.

One reason webhooks become annoying for consumers is that every provider invents slightly different signing schemes, headers, and retry behavior. Svix is involved with Standard Webhooks, an open-source initiative defining common tools and guidelines for secure and reliable webhook delivery, with the goal of reducing the need for every provider and consumer to reinvent the same patterns, including protections against spoofing, replay attacks, and SSRF. The spec is steered by a committee including Zapier, Twilio, Lob, Mux, ngrok, Supabase, Svix, and Kong.

I don't think the important lesson here is "everyone needs webhooks." It is that state changes should be first-class architectural objects. Database teams learned this with logs and CDC. Cloud architects learned it with queues, pub/sub, EventBridge and Event Grid. Streaming teams learned it with Kafka and Event Hubs. The application boundary should not automatically be exempt.

Polling remains an excellent tool when the consumer needs to control cadence, when batching is desirable, when the producer cannot emit events, or when simplicity matters more than immediacy. But if the producer already knows that something happened, and the consumer needs to know promptly, continuously asking whether it happened is often an unnecessary coordination mechanism.

And once you decide to expose events to customers, partners, or autonomous systems, the next question is whether you really want to spend engineering time building and operating the delivery infrastructure around them. For many organizations, that is where a service such as Svix becomes interesting. Not because sending an HTTP request is difficult. Because reliably operating the system around that HTTP request is infrastructure. And infrastructure has a way of becoming somebody's pager.

Svix provides webhook infrastructure for teams that want to expose reliable event delivery without building the full delivery subsystem themselves. It includes retries, security, observability, customer-facing management, and multiple delivery destinations, with both managed and open-source deployment options.

Explore Svix →

P.S. Svix sponsored this issue — if the build-vs-buy section hit close to home, start here.

— Gladstone