Long Polling

How Long Polling Works

Long polling is a request pattern that keeps an HTTP request open until the server has fresh data or a timeout occurs. That changes the usual request-response rhythm into a wait-and-deliver model, so the client can receive updates with less repeated polling traffic and lower overhead than frequent short requests.

The core idea is simple: the client asks, the server holds the connection, and the server responds only when there is something meaningful to return. In practice, that makes long polling useful when a system needs near real-time delivery but must still work through standard web infrastructure and conventional HTTP semantics.

Because the connection stays open, the pattern behaves differently from ordinary polling in terms of latency, concurrency, and resource usage. It can feel event-driven to the application while still being implemented with request handling that many platforms, proxies, and APIs already understand.

Where Long Polling Fits in Web Applications and APIs

Long polling is often chosen when a system needs timely updates but cannot rely on persistent push channels everywhere. It is common in web applications, APIs, notification systems, chat-like experiences, job status updates, and event delivery flows where the server may not have new data immediately.

It also acts as a compatibility bridge. Some environments can support WebSockets or server-sent events, but long polling remains attractive where developers want a simpler transport path, better intermediary compatibility, or a fallback that works with standard HTTP request handling.

For API designers, the pattern matters because the endpoint is not just returning data, it is managing wait time, response timing, and client reconnection behavior. That means the contract includes both the event itself and the operational behavior around how long a request may remain open before the client retries.

Operational Trade-offs and Failure Modes

Long polling reduces repeated request noise, but it shifts pressure into connection management. Servers may need to hold many open requests at once, and load balancers, reverse proxies, or gateways can become part of the effective timeout path even when the application itself is healthy.

Timeouts, reconnect storms, and uneven retry behavior are the common failure modes. If a server times out too aggressively, clients may fall back to frequent retries and create avoidable load; if it holds connections too long, resource consumption can increase and slow response handling for other traffic.

The pattern also depends on well-tuned back-end event delivery. If updates arrive faster than clients can reconnect, or if the delivery layer is inconsistent, long polling can still feel delayed or bursty even though the underlying idea is near real-time communication.

Security and Reliability Considerations for Long Polling

Long polling is not inherently insecure, but it does widen the operational surface around availability, session handling, and request exhaustion. A large number of held-open requests can amplify resource consumption, and poorly controlled retries can create noisy traffic that obscures genuine application activity. The OWASP API Security Top 10 is a useful reference point when designing APIs that must stay responsive under sustained or repeated client demand.

Failure mechanism: long-lived requests consume worker slots, file descriptors, memory, or gateway capacity, while client retry behavior can compound the load if timeouts are inconsistent across layers.

Impact: the result can be degraded availability, delayed event delivery, and reduced visibility into whether slow responses are normal back-pressure or an emerging service problem.

Related resources from NHI Mgmt Group

• What is the biggest long-term risk of unmanaged NHIs multiplying at exponential rates?
• When does a short-lived credential still become a long-term risk?
• Should organisations use SSH certificates instead of long-lived keys?
• When do long-lived machine secrets become unacceptable risk?