Polling, Long Polling, SSE & WebSockets

Choose from direction, urgency, and connection lifetime#

“Real time” is not a protocol requirement. Ask who initiates updates, whether the client sends independently, how much delay is acceptable, how many connections must remain open, and what happens after a disconnect.

Four useful mechanisms#

Polling

The client asks periodically. It works with ordinary HTTP infrastructure and is easy to operate, but empty checks waste work and update latency follows the interval.

Client → Server: Any updates?
Client → Server: Any updates?
Client → Server: Any updates?

Long polling

The server holds a request until data is available or a timeout occurs, then the client immediately reconnects. It approximates server push while retaining repeated HTTP requests.

Server-Sent Events

SSE maintains an HTTP response stream from server to browser. It is one-directional and browser EventSource handles reconnection behavior. It fits notifications, dashboards, and streamed server updates when client messages can use normal requests.

WebSockets

A WebSocket is a long-lived bidirectional channel. Client and server can send independently, so chat, presence, multiplayer, and live collaboration may fit. The application still owns authentication refresh, heartbeats, idle policy, backpressure, reconnect, and missed-event recovery.

The hard part starts after the connection opens#

User A may be connected to Gateway A while User B is connected to Gateway B. The system needs a presence or connection registry to locate B and a routing path, often Pub/Sub or a broker, between gateways. Sticky routing can help reconnect a client to a gateway but does not route messages between different users.