WebSockets and Long Polling

Standard Polling: The Periodic Request

Standard polling is the most straightforward mechanism for client-server communication. The client sends a regular HTTP GET request to the server at predefined intervals, such as every five seconds. If the server has new data, it responds with the payload; if not, it sends an empty response. This approach relies on standard stateless HTTP, making it extremely easy to implement and debug. However, it suffers from significant inefficiencies. First, the client incurs the overhead of repeated TCP handshakes and HTTP header transmissions, even when no new information exists. Second, there is an inherent 'update lag'—the time elapsed between the server receiving new data and the next polling interval—which leads to poor user experiences in high-velocity environments like financial tickers or live chat. It is only suitable for non-critical, slow-changing data.

async function poll(url, interval) {
  // Continuously request data at a fixed interval
  setInterval(async () => {
    const response = await fetch(url);
    const data = await response.json();
    console.log('Update received:', data);
  }, interval);
}

Long Polling: Minimizing Dead Intervals

Long polling improves upon standard polling by keeping the client request open until the server actually has new data to return. When the client sends an HTTP request, the server intentionally delays its response until an event occurs or a timeout threshold is reached. Once the server sends the response, the client processes it and immediately initiates a new request to wait for the next update. This eliminates the polling frequency issues seen in standard polling and ensures that updates are delivered as close to real-time as possible. While more efficient than standard polling, it still involves the overhead of opening and closing connections repeatedly. It also imposes a strain on the server, which must hold many idle connections open, consuming file descriptors and memory. This technique is an excellent fallback for browsers or infrastructure that do not support modern persistent protocols.

async function longPoll(url) {
  // Wait for the server to reply before starting the next request
  const response = await fetch(url);
  if (response.ok) {
    const data = await response.json();
    console.log('Data processed:', data);
    longPoll(url); // Recursive call ensures a new connection is established
  }
}

The WebSocket Protocol: Persistent Full-Duplex

WebSockets provide a true full-duplex communication channel over a single TCP connection, fundamentally changing how clients and servers interact. Unlike HTTP, which is request-response based, a WebSocket connection begins with an HTTP upgrade handshake that switches the protocol to a persistent binary stream. Once the connection is established, the overhead of headers is virtually eliminated because the protocol uses compact frames. Because the connection remains open, the server can push data to the client at any time without waiting for an explicit request. This low-latency architecture is perfect for high-frequency gaming, live collaborative editing, or real-time notification systems. Because these connections are stateful, servers must implement logic for heartbeat 'pings' to ensure the connection is still alive, and developers must handle connection drops or network interruptions gracefully, unlike stateless HTTP requests.

const socket = new WebSocket('ws://server.example.com');

// Handle connection opening and push messages
socket.onopen = () => socket.send('Hello Server!');
socket.onmessage = (event) => {
  console.log('Push update received:', event.data);
};

Connection Management and Load Balancing

When moving from simple request-response to persistent WebSockets, your load balancing strategy must evolve significantly. Traditional HTTP load balancers often operate by distributing individual requests; however, a WebSocket connection lasts indefinitely, meaning a standard round-robin approach might lead to an uneven distribution of active connections. You must implement sticky sessions or connection-aware load balancing to ensure that a client's persistent connection is routed consistently. Furthermore, every open WebSocket connection consumes a socket file descriptor on your server, setting a hard limit on how many concurrent users a single instance can handle. To scale horizontally, you need an external message broker to synchronize state across multiple server instances, ensuring that if a user sends a message to server A, it can be broadcast to users connected to servers B and C. Failing to account for this state synchronization will result in fragmented user experiences.

// Broadcast message across multiple server nodes via a broker
function broadcast(channel, data) {
  // The message broker (like Redis) propagates this to all server instances
  broker.publish(channel, JSON.stringify(data));
}

Choosing the Right Mechanism

Selecting the optimal communication strategy requires a balanced analysis of system requirements versus operational cost. For internal monitoring or static dashboards where updates are infrequent, standard polling is often sufficient and avoids unnecessary complexity. For systems that need real-time responsiveness but operate in environments with legacy limitations, long polling is a reliable middle ground that reduces latency without complex state management. However, for any modern application that demands high throughput and low-latency interaction, WebSockets are the industry standard. Always remember that persistence comes with a price: state management, memory usage, and load balancing complexities. Before committing to WebSockets, evaluate whether the complexity of maintaining long-lived connections is justified by the performance gains. If you only need server-to-client updates without client-to-server interaction, you might even consider Server-Sent Events as a lighter alternative to full-duplex WebSockets.

function selectStrategy(needsRealTime) {
  if (needsRealTime) {
    return 'WebSocket'; // Best for high-frequency events
  } else {
    return 'Polling'; // Best for low-frequency, simple updates
  }
}

Interview questions

All System Design interview questions →

Check yourself

Take the full System Design quiz →