[System Design]: Short polling vs Long polling vs Push vs WebSocket

Polling(Short Polling) :

When client is simply asking the backend/service whether it has certain information and backend supposed to reply with relevant response( eg. request/response model) i.e do I have any new messages? Server will check every time you “poll” and every time client is responsible to request again and again for anything new needed ! This would put lots of load on backend of course! Cons: latency, bandwidth consumption, too many requests, not real-time
When to use: Never :-)

Polling(Long Polling) :

Client asks the server and waits until server gives back response or timeout threshold is reached.
When to use: Possibly when query for the same request wont happen again and again; single call to the server needs long polling connection as server may be busy with other work when the client asks for certain data.

Pushing (Stateless) :

It is opposite to polling; server doing all the hard work pushing the stuff to the client. ex: Push notifications. Remember, server needs to know “where the client is now? Is it connected now?” to send out notifications. That means, server needs to keep track the client connection status all the time.
When to use: If there is a need to deliver messages to the client even when the application is not running or the website is not opened

WebSocket:

It is bi-directional and persistent connection started by client. It means, a WebSocket connection can both send data to the app and receive data from the app. WebSocket can work even when firewall is in place. Also it allows servers to push data directly to the browser through a connection that stays continuously open. So WebSockets are less resource intensive on server compared to Long Polling.
When “not” to use: Not so useful if only a small number of messages will be sent or if the data exchange is very infrequent. Unless the client need to quickly receive or take action of updates, maintaining the open connection may be unnecessary waste of resources. Also, WebSockets are not designed for media-rich data transfer.
When to use: For real-time web applications, chat applications

How WebSockets work?

WebSockets are a thin layer built on top of a device’s TCP/IP stack. So anything beyond the basic handshake and specification for message framing is really something that needs to be handled either on a per-application or per-library basis.

WebSockets usually starts with HTTP request and response. Within that window, the client asks to open a WebSocket connection, and the server responds to it, if it can. If this initial handshake is successful, the client and server would have the quorum to use the existing TCP/IP connection that was established for the HTTP request as a WebSocket connection. Data can now flow over this connection. When the server loses the connection with client, usually websocket connection will be closed.