The Future is Event-Driven

It's time we stop polling. I mean, polling has its place. It's extremely easy to setup, it's easy to reason about, and it works with everything that has an API. Though we still need to stop with all the polling.

This is not a new problem. People have been switching from polling to event-driven for years, however that shift has accelerated significantly over the last 12 months. We see it with our customers at Svix, though it's also visible on Google Trends, where search volume for event-driven has increased 10x in the last 12 months.

Why polling is breaking down

This is happening because there are a few major problems with polling: cost, latency, and developer experience. Polling is very expensive from a compute (and thus resources) standpoint, since polling means each one of your customers hits your APIs dozens of times a minute. With 10,000 customers that's hundreds of thousands to millions of mostly useless API calls every minute. Latency is also a problem, because to rein in costs, people tend to increase their polling intervals. Higher polling intervals means that polling tends to not be in real-time but often delayed. As for the developer experience, most APIs don't provide an easy way to figure out what changed, which leads to complex logic on the consumer, and an ever higher load.

AI agents and the polling problem

Though now with agent workflows these become much more acute. The polling load is significantly higher as there is an increasing number of agents, the latency becomes even more important as we expect agents to act in real-time, and the complexity of understanding what changed leads to higher token costs.

This is not just a more agents == more load kind of math. Agent workflows are much more complex than past workflows often having a long chain of events and triggers. In practice this means an exponential explosion in growth, and a latency penalty for each event-driven step which takes what was previously a 10s latency, and turns it into a 100s one.

In this future agent-filled world, the only option is to go event-driven. Otherwise, everything will just buckle under the load. GitHub's uptime in the last 12 months is just the canary in the coal-mine; though agent based load is coming for the rest of SaaS as well.

Webhooks and the future of event-driven architecture

So why are we still polling? Event-driven architectures tend to be more complex and harder to reason about, and the tools to support great event-driven are just not there yet.

Webhooks won the cross-service event-driven APIs, though even they have a long way to go in order to serve the event-driven needs of the future. We've already improved webhooks significantly with things like Standard Webhooks which has been adopted by many amazing companies, including the addition of OpenAI, Anthropic, and Google Gemini in the last 12 months alone.

Webhooks, however, are only part of the story. Agents and non-agent workflows would need much better tooling in order to sustain the event-driven needs of the future. They will need to be real-time, easy to reason about, agent-accessible, reliable, and scalable.

Ultimately, the teams that are able to adopt event-driven systems and wire them into their agentic systems well will win, full stop. As ramping token costs and time inefficiencies add up, polling will kill fanned-out integrations and meaningful attempts at creating lasting workflows.

The future is event-driven, though there's more work to be done to make sure we are all ready for it.

For more content like this, make sure to follow us on X / Twitter, Mastodon, Github, RSS, or our newsletter for the latest updates for the Svix webhook service, or join the discussion on our community Slack.