Pick the Right Real‑Time Communication: Short Polling, Long Polling, WebSocket, SSE

1. Short Polling

Browser periodically (e.g., every second) sends an HTTP request; server immediately returns current data regardless of updates.

Advantages : Simple to implement, excellent compatibility.

Disadvantages : High request frequency wastes resources, poor real‑time performance (depends on poll interval).

Latency : High (depends on poll frequency).

Suitable scenarios : Simple cases requiring high compatibility and insensitive to latency, e.g., score live updates.

Example: live score broadcasting where the browser polls for match updates and re‑renders the page when data changes.

2. Long Polling

Browser sends an HTTP request; server holds the connection until data changes or timeout, then returns a response and the browser immediately opens a new request.

Advantages : Reduces unnecessary requests, better real‑time than short polling.

Disadvantages : Server must keep connections open, high resource consumption under high concurrency.

Latency : Medium (depends on data update frequency).

Suitable scenarios : Situations needing decent real‑time where WebSocket/SSE cannot be used, such as message notifications.

Common use: configuration centers like Nacos and Apollo rely on long polling.

After a client request, Nacos keeps the request pending; if data changes within the waiting period, it responds immediately; otherwise it replies after a timeout, and the client re‑issues a long‑poll request.

3. WebSocket

Based on TCP full‑duplex protocol, establishes a persistent connection via an HTTP upgrade handshake ( Upgrade: websocket) for bidirectional real‑time communication.

Advantages : Lowest latency, supports bidirectional interaction, saves bandwidth.

Disadvantages : More complex to implement, requires handling connection state.

Latency : Extremely low.

Suitable scenarios : Chat rooms, online games, collaborative editing, any high‑real‑time bidirectional interaction.

Author’s experience: developed a live‑quiz feature for an e‑commerce platform using WebSocket.

4. Server‑Sent Events (SSE)

Based on HTTP, the server can actively push a data stream (e.g., Content-Type: text/event-stream) and the browser listens via the EventSource API.

Advantages : Native reconnection support, lightweight (HTTP).

Disadvantages : Unidirectional (server → client), not supported by older IE browsers.

Latency : Low (server can push instantly).

Suitable scenarios : Stock quotes, real‑time logs, any case where the server only needs to push data.

Classic example: DeepSeek web chat where the browser sends a request and the server returns messages via SSE.

5. Summary and Recommendations

Choose the technique based on requirements:

Need simple compatibility → Short Polling.

Need moderate real‑time → Long Polling.

Need server‑push only → SSE.

Need full‑duplex real‑time interaction → WebSocket.