Long Polling vs SSE vs WebSockets: Choose the Right Real-Time Protocol

Most real-time systems fail not because the protocol is slow, but because the wrong protocol was chosen. I've seen a chat app built on long polling bring a server farm to its knees at 2 PM on Black Friday. The team assumed 'real-time' meant WebSockets, but their ops team blocked WebSocket upgrades at the load balancer. They ended up with a polling loop that looked like a DDoS against themselves.

The problem is simple: you need the server to push data to the client without the client asking. The browser's HTTP request-response model doesn't support that natively. So we hacked around it. Long polling was the first hack. Then came SSE and WebSockets. Each trades off latency, complexity, and resource usage.

By the end of this, you'll be able to pick the right protocol for your use case, spot the failure modes before they hit production, and defend your choice in a system design interview. No fluff. Just what works and what doesn't.

Long Polling: The Hack That Won't Die

Long polling exists because HTTP 1.0 had no push mechanism. The client sends a request, the server holds it open until it has data (or a timeout), then responds. The client immediately sends another request. It's not real push — it's a loop that looks like push.

The problem? Every poll is a full HTTP request with headers, cookies, and TLS handshake overhead. At scale, that overhead kills you. I've seen a 50-node cluster reduced to 10% throughput because every client polled every 5 seconds. The network stack was drowning in SYN packets.

When does long polling make sense? When you can't upgrade the server or the client. Think embedded devices with minimal HTTP libraries, or legacy systems where you can't install WebSocket support. Otherwise, don't touch it.

// io.thecodeforge — System Design tutorial
// Long polling server using Node.js (naive, for illustration)
const http = require('http');

const clients = []; // WARNING: in production, use a proper queue

http.createServer((req, res) => {
  if (req.url === '/poll') {
    // Hold the response open until we have data or timeout
    clients.push(res);
    req.on('close', () => {
      // Clean up if client disconnects early
      const idx = clients.indexOf(res);
      if (idx !== -1) clients.splice(idx, 1);
    });
    // Timeout after 30 seconds to prevent resource leak
    setTimeout(() => {
      if (!res.writableEnded) {
        res.end('[]'); // empty response
      }
    }, 30000);
  } else if (req.url === '/push') {
    // Simulate pushing data to all polling clients
    let body = '';
    req.on('data', chunk => body += chunk);
    req.on('end', () => {
      clients.forEach(client => {
        client.end(body);
      });
      clients.length = 0;
      res.end('ok');
    });
  }
}).listen(3000);
console.log('Long poll server on :3000');

SSE: The Underrated Workhorse

Server-Sent Events (SSE) is a standard that lets the server push text events over a single long-lived HTTP connection. The client uses EventSource API. It's unidirectional — server to client only. That's fine for live feeds, stock tickers, notifications, and log streaming.

Why isn't SSE more popular? Because WebSockets got all the hype. But SSE has advantages: it works over plain HTTP/1.1 (no upgrade handshake), automatically reconnects with last-event-id, and is simpler to implement. The downside: browser limits on concurrent connections (typically 6 per domain) and no binary data without base64 encoding.

I've used SSE to replace a WebSocket-based notification system that kept dropping connections under load. The EventSource auto-reconnect saved us from writing reconnection logic. The 6-connection limit? We sharded across subdomains.

// io.thecodeforge — System Design tutorial
// SSE server using Node.js
const http = require('http');

http.createServer((req, res) => {
  if (req.url === '/events') {
    // Set SSE headers
    res.writeHead(200, {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive',
      'Access-Control-Allow-Origin': '*'
    });

    // Send a keepalive comment every 15 seconds to prevent proxy timeout
    const keepalive = setInterval(() => {
      res.write(': keepalive\n\n');
    }, 15000);

    // Simulate sending events
    let eventId = 0;
    const sendEvent = setInterval(() => {
      const data = JSON.stringify({ id: ++eventId, message: 'Hello ' + eventId });
      res.write(`id: ${eventId}\nevent: message\ndata: ${data}\n\n`);
    }, 2000);

    req.on('close', () => {
      clearInterval(keepalive);
      clearInterval(sendEvent);
    });
  }
}).listen(3001);
console.log('SSE server on :3001');

WebSockets: Full-Duplex, But at a Cost

WebSockets provide a persistent, full-duplex connection over a single TCP socket. The client and server can send messages anytime. It's the go-to for low-latency bidirectional communication: chat, gaming, collaborative editing, financial tick data.

The cost? Complexity. You need a WebSocket library on both sides. You need to handle reconnection, heartbeats, and message framing yourself. WebSocket connections don't automatically reconnect like SSE. And they don't work through all proxies — many corporate firewalls strip the Upgrade header.

I once debugged a WebSocket outage where the load balancer's idle timeout was 60 seconds, but the WebSocket heartbeat was every 120 seconds. Connections were silently killed. The fix: set the heartbeat interval to 30 seconds and configure the load balancer to not timeout WebSocket connections.

// io.thecodeforge — System Design tutorial
// WebSocket server using Node.js (ws library)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 3002 });

wss.on('connection', (ws, req) => {
  console.log('Client connected from', req.socket.remoteAddress);

  // Heartbeat to detect dead connections
  ws.isAlive = true;
  ws.on('pong', () => { ws.isAlive = true; });

  // Handle incoming messages
  ws.on('message', (message) => {
    // Echo back for simplicity
    ws.send(`Echo: ${message}`);
  });

  // Send a welcome message
  ws.send(JSON.stringify({ type: 'welcome', message: 'Connected' }));
});

// Heartbeat interval: every 30 seconds
const heartbeat = setInterval(() => {
  wss.clients.forEach((ws) => {
    if (ws.isAlive === false) {
      return ws.terminate();
    }
    ws.isAlive = false;
    ws.ping();
  });
}, 30000);

wss.on('close', () => clearInterval(heartbeat));
console.log('WebSocket server on :3002');

When to Use What: A Decision Framework

Here's the rule of thumb I use:

• Need bidirectional, low-latency, and can control the network? WebSockets.
• Need server-to-client streaming only, and want simplicity? SSE.
• Can't upgrade the server or client, or need to traverse restrictive proxies? Long polling.
• Need binary data? WebSockets (or SSE with base64, but that's wasteful).
• Need to support millions of concurrent connections? SSE or WebSockets with async I/O. Long polling won't scale.

The browser's EventSource API limits you to 6 concurrent connections per domain. If you need more, use subdomains or switch to WebSockets. Also, SSE doesn't support custom headers — you can't send authentication tokens in the initial request. Workaround: use query parameters or cookies.

Production Gotchas: What Will Burn You

1. Proxy timeouts: Load balancers, reverse proxies, and CDNs have idle timeouts. If your SSE or WebSocket connection sends no data for longer than the timeout, the proxy kills it. Fix: send keepalive pings (SSE: comment line; WebSocket: ping/pong).
2. Connection limits: Browsers limit concurrent connections per domain (usually 6). If you open multiple SSE streams, you'll hit the limit. Fix: use subdomains or switch to WebSockets (which have a different limit, typically 255 per domain).
3. Reconnection storms: When a server restarts, all clients reconnect simultaneously. This can overwhelm the server. Fix: implement exponential backoff with jitter on the client side. For SSE, the EventSource API supports this natively with the 'reconnection time' field.
4. Memory leaks: Each connection holds server resources. If clients disconnect without proper cleanup, you leak memory. Fix: implement connection cleanup on close events and use heartbeats to detect dead connections.