Build fluency in the vocabulary of holding a request open until new data actually exists.
0 / 5 completed
1 / 5
At standup, a dev mentions a client holding a request open until the server actually has new data to send, then immediately reopening a new request, rather than the client asking again every few seconds regardless of whether anything changed. What is this technique called?
Long polling has the client hold a request open until the server actually has new data to send, then immediately reopen a new request to wait for the next update, rather than repeatedly asking again on a fixed interval regardless of whether anything changed. Short polling is exactly that repeated fixed-interval approach, which wastes requests when nothing has changed and adds latency when something has. This held-open-request approach is what lets long polling deliver near-real-time updates without a client needing to ask constantly.
2 / 5
During a design review, the team compares long polling's held-open connection against plain short polling's fixed-interval requests for a chat feature that needs near-instant message delivery. Which capability does long polling provide that short polling doesn't?
Long polling provides lower latency for a new message, since the server can respond the moment new data actually exists, rather than the client having to wait for its next scheduled poll under short polling, which could be several seconds away even after the message has already arrived. Assuming both approaches share the same latency ignores exactly this held-open-connection advantage long polling offers. This is why long polling was historically favored for a chat-like feature over short polling before WebSockets became widely supported.
3 / 5
In a code review, a dev notices the server is holding several thousand long-poll connections open simultaneously, each consuming a thread or a connection slot while waiting for new data to arrive. What does this represent?
This is the resource cost of long polling at scale, since each held-open connection consumes server capacity, whether a thread, a socket, or a connection slot in an event loop, for as long as it waits for new data, and that cost multiplies directly with the number of simultaneously connected clients. A schema registry is an unrelated concept about validating a message's format. This resource cost is exactly why long polling doesn't scale as gracefully as an approach like WebSockets, which can hold many idle connections far more cheaply.
4 / 5
An incident report shows a server ran out of available threads and started rejecting new requests entirely, because tens of thousands of long-poll connections were being held open simultaneously and each one consumed a dedicated thread while waiting. What practice would prevent this?
Migrating to a connection model that scales more cheaply per idle client, such as WebSockets or an event-loop-based server design, avoids tying up a dedicated thread for every single held-open connection, letting the server support far more simultaneous clients with the same resources. Continuing to hold every connection open on a dedicated thread regardless of client count is exactly what exhausted the server's threads in this incident. This migration is the standard response once long polling's thread-per-connection cost has become the actual bottleneck at scale.
5 / 5
During a PR review, a teammate asks why the team still supports long polling as a fallback instead of relying entirely on WebSockets for real-time updates. What is the reasoning?
A WebSocket connection can be blocked by a restrictive proxy or firewall that doesn't support the protocol upgrade, which is a real constraint in some corporate or institutional network environments. Long polling works over plain HTTP, which almost every proxy and firewall already supports, making it a reliable fallback exactly in the environment where WebSockets might fail. The tradeoff is that the long-polling fallback carries the higher per-connection resource cost discussed earlier, which is why it's kept as a fallback rather than the primary mechanism wherever WebSockets are available.