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.
What does the "Long Polling Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to long polling vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.