Long Polling
In traditional short polling, clients frequently send requests to check if a job is done. While simple, this approach consumes a lot of network bandwidth. To address this issue, many systems adopted Long Polling.
But how exactly does Long Polling solve the problem? Let’s explore 👇
🔁 How Long Polling Works:
-
The client sends a request.
-
The server responds immediately with a job handler (like a job ID).
-
The client then sends a request to check the job status.
-
Here’s the trick: the server does not respond unless the result is ready.
This approach reduces network bandwidth usage because the client is not constantly sending requests like in short polling.
However, there’s a trade-off: the server still consumes resources since it must keep the connection open and monitor when the result is available.
You can think of Long Polling as shifting the polling logic from the client to the server. In practice, it’s as if the server is polling internally, or even applying something similar to the Observer pattern to detect when the job is complete and immediately send a response.
Another benefit is flexibility — the client can disconnect and reconnect later to check the job status, much like in short polling, but with reduced network strain.