Poll/Push

In short: Two opposing strategies for keeping data up to date: with polling, the client regularly and actively asks for new data; with push, the server sends it on its own as soon as it’s available.

In more detail: Polling is easy to implement but wastes resources if the answer is often “nothing new”. Push mechanisms (e.g. WebSockets, server-sent events, mobile push notifications) are more efficient, but need a permanent connection or an external push service.

In Depth

Polling can be divided further: with “short polling”, the client asks at a fixed interval (e.g. every 5 seconds), regardless of whether there’s anything new — simple, but inefficient with infrequent updates. “Long polling” improves on this: the client makes a request, but the server only answers it once new data is actually available (or a timeout is reached) — to the user this feels almost like push, but technically it remains a request/response chain.

Real push needs an open, bidirectional connection over which the server can send on its own at any time — WebSockets are the most widespread solution for this on the web, while server-sent events (SSE) are a simpler variant for server-to-client push only, building on normal HTTP instead of needing a protocol of their own. In mobile apps, central push services (Apple Push Notification service, Firebase Cloud Messaging) take on this task, so that not every app has to keep its own permanent connection open individually — which considerably saves battery and bandwidth on mobile devices.

Weighing it up in practice

The choice between the two strategies depends heavily on how time-critical freshness is and how often data actually changes. A dashboard showing stock prices in real time benefits massively from push — with short polling you’d either have to ask very often (wasting resources when prices are stable) or accept stale data. An email client that only needs to check for new messages every few minutes, on the other hand, gets along fine with simple polling, without the complexity of a permanent connection. Many real systems combine both approaches: an initial request via polling, which is “upgraded” to a push connection when needed.

Server-side scaling questions

Push connections also have an often underestimated downside on the server side: every open WebSocket or SSE connection occupies memory and a file descriptor on the server for as long as it exists — with millions of simultaneous users this can cause considerable infrastructure costs, while stateless polling requests are easier to distribute across many servers (load balancing), because each request is independent of the previous ones.

See also: Streaming