Long polling vs short polling
Short polling has the client ask the server for updates on a fixed timer and get an answer straight away, empty or not. Long polling has the server hold each request open until it actually has something to send. Both imitate push over plain HTTP; long polling trades held connections for lower latency.
How short polling works
The client sends a request every few seconds and the server replies immediately with whatever it has. Most of those replies are empty, which is the whole cost of the technique: if updates arrive once a minute and you poll every five seconds, eleven out of twelve requests did nothing but burn a round trip. In exchange you get something genuinely simple. Each request is independent, nothing is held open, and a client that crashes just stops asking. Caching, load balancers, and timeouts all behave normally because the traffic looks like ordinary API calls.
Short polling fits data that changes on a schedule you already know, such as a nightly report status, a health check, or a feed where being a minute stale costs nothing.
How long polling works
The client sends a request and the server does not answer until an update exists or a timeout expires, usually somewhere between 20 and 60 seconds. When the response finally comes back the client immediately opens another request, so there is almost always a connection waiting. Updates reach the client within milliseconds of being available rather than on the next tick of a timer.
The price is that every waiting client occupies a connection and, depending on your server model, a thread or a goroutine. A thousand idle clients on short polling is a thousand brief requests spread over time; on long polling it is a thousand connections held open at once. That is fine on an event-driven server and expensive on a thread-per-request one. Long polling also needs more care around edge cases: proxies that kill idle connections, clients that reconnect in a tight loop after an error, and duplicate delivery when a response is sent as the client gives up.
What each costs you
Short polling wastes requests but keeps state on the client. Long polling wastes almost no requests but moves state onto the server, which now has to track who is waiting and wake them up. Which one is cheaper depends on the ratio between your polling interval and how often data actually changes. Poll infrequently against data that rarely changes and short polling wins on simplicity. Poll every second because users expect near-instant updates and long polling is doing strictly less work for a better result.
Neither approach scales as well as a protocol designed for the job. Both are workarounds for HTTP's request/response shape, which is why they lose to server-sent events or WebSockets once you can rely on those being available.
Choosing between them
Pick short polling when the update interval is measured in minutes, the client count is high, and simplicity matters more than freshness. Pick long polling when users notice a delay of a few seconds and you cannot use a streaming protocol, which is common behind older proxies or in environments where only plain HTTP gets through.
If the updates come from another company's system rather than your own, polling is usually the wrong frame entirely. Webhooks invert the direction so the provider tells you when something happened instead of you asking on a loop. Our comparison of webhooks and long polling covers that tradeoff, and Svix handles the delivery side for teams sending those events to their own users.