Event-driven vs polling: the cost of asking versus being told

Quick answer

Polling repeatedly asks whether something changed, burning compute and requests on checks that usually return nothing. Event-driven architectures act only when an event actually occurs, so they do work, and cost, in proportion to real events rather than to how often you check. For infrequent events, event-driven is dramatically cheaper; for constant high-frequency change, the gap narrows.

Two ways to know when something changes: poll (ask repeatedly) or subscribe to events (be told). The cost difference is large and often overlooked. Polling pays for every check whether or not anything happened, so a system polling every few seconds for an event that occurs a few times a day does thousands of times more work than the events warrant.

Polling pays for the checks

A poller runs on a schedule, making a request each time to see if there is new work. Most of those requests find nothing, but you pay for all of them, in compute (the poller running), in requests (API calls, database queries), and sometimes in downstream load. The cost scales with polling frequency, not with how often the thing you care about actually changes.

Event-driven pays for the events

	Polling	Event-driven
Work done	Every check, mostly empty	Only on real events
Cost scales with	Polling frequency	Event frequency
Latency	Up to the polling interval	Near-immediate
Best for	Constant high-frequency change	Infrequent or bursty events

An event-driven system, using webhooks, queues, or event buses, triggers work only when an event occurs. A serverless function invoked per event costs per event, so for infrequent events it does almost nothing between them, and it also delivers lower latency, since it reacts immediately rather than waiting for the next poll.

When polling still makes sense

Polling is not always wrong. For very high-frequency, near-constant change, the poller is busy anyway, so the empty-check overhead is small, and polling can be simpler and avoid event-delivery complexity. Some systems only offer polling (no events available). And a slow poll (every few minutes) for a genuinely low-urgency check can be cheaper and simpler than event plumbing.

Choosing for cost

Prefer event-driven for infrequent, bursty, or latency-sensitive changes, where paying per event beats paying per check and you get immediate reaction. Use polling only for constant high-frequency change or where events are unavailable, and if you must poll, lengthen the interval to the least frequent your latency requirement allows. The saving from replacing frequent polling with events is one of the larger architectural cost wins available, in the spirit of event-based messaging.

FAQ

Why is polling expensive?

Because it pays for every check whether or not anything changed. A system polling every few seconds for an event that occurs a few times a day does thousands of times more work than the events warrant, in compute, requests, and downstream load. Cost scales with polling frequency, not with real change.

How is event-driven cheaper than polling?

An event-driven system does work only when an event actually occurs, so cost scales with event frequency rather than check frequency. For infrequent events, it does almost nothing between them, unlike a poller running constantly. It also delivers lower latency by reacting immediately.

When does polling still make sense?

For very high-frequency, near-constant change, where the poller is busy anyway so empty-check overhead is small; where only polling is available (no events offered); and for genuinely low-urgency checks where a slow poll every few minutes is simpler and cheaper than event plumbing.

How do I reduce polling cost?

Prefer event-driven architectures (webhooks, queues, event buses) for infrequent or bursty changes so you pay per event, not per check. Where you must poll, lengthen the interval to the least frequent your latency requirement allows, since cost scales directly with polling frequency.

Does event-driven improve latency too?

Yes. Event-driven systems react as soon as an event occurs, while polling adds latency up to the polling interval (you learn of a change only at the next poll). So event-driven often improves both cost and latency, which is unusual among architectural tradeoffs.

Does C3X estimate the cost of event-driven versus polling?

C3X prices the infrastructure of either approach from your Terraform, the pollers, functions, queues, and event buses. The cost difference depends on your polling frequency versus event frequency, which you model as usage assumptions to compare the two designs before building.

What to do next

Compare architectural approaches before you build. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.