Short polling, Long polling, and Server-side events

In this blog, I am going to share my understanding of short polling, long polling and server-side events which I learnt in my system design classes.

Polling

Polling refers to the process of communication b/w the client and server, where the client repeatedly sends requests to the server to get updated information.

Short Polling

Short polling is a technique in which a client keeps sending requests to the server in fixed intervals. The server will send response, either with data if it is available or the current state/empty response if there is no changes/data is not available.

Here, the tradeoff is b/w getting updated information and sending more requests which increases load.

Example:

Let us take the case of LeetCode where we see the number of users currently viewing a particular question.

In case of short polling, when requests are sent in a particular interval of time, the server sends either

200 GET /user-count { users: 7258 } if no updates, or

200 GET /user-count { users: 7262 } if user count changes.

Long Polling

Long polling is a technique in which when a client sends a request, the server holds it until new data is available or a timeout occurs. After the client receives the response, it will again send the request to fetch updated data.

Here, the server keeps multiple open requests, which consumes multiple resources, limiting scalability. (One such scenario is, when requests are sent through ports that are limited in number, the server might not be able to receive many incoming requests.)

Example:

In the same LeetCode scenario, when long polling happens only updates on data will be sent as response like,

200 GET /user-count
... (takes time)
{ users: 7260 }

200 GET /user-count
...
{ users: 7000 }

Event Streams / Server-Sent Events

In this technique, a connection b/w the client and server is established, and the server keeps sending data updates through that connection. The client sends request only once. The communication happens through a persistent HTTP connection.

Here, the communication is unidirectional, where the data flows only from server to client and not vice versa.

Example:

In the LeetCode scenario, one single request will give multiple responses like

200 GET /user-count

{ users: 7260 }

{ users: 7270 }

{ users: 7290 }

{ users: 7200 }

{ users: 6860 }