Long Polling vs Short Polling

Why Polling?

WebSockets and SSE are powerful, but they require persistent connections and specialized infrastructure. Polling is the oldest and simplest approach to near-real-time data: the client periodically asks the server if anything has changed. Despite being less efficient than push-based approaches, polling remains relevant in many real-world situations.

Short Polling

Short polling sends an HTTP request to the server at a fixed interval. The server responds immediately with whatever data is available (even if nothing has changed), and the client schedules the next request.

// Short polling: check every 5 seconds
function startShortPolling(userId) {
  const poll = async () => {
    try {
      const response = await fetch(`/api/notifications/${userId}`);
      const data = await response.json();
      if (data.notifications.length > 0) {
        renderNotifications(data.notifications);
      }
    } catch (err) {
      console.error('Poll failed:', err);
    }
  };

  poll(); // Immediate first call
  return setInterval(poll, 5000); // Then every 5s
}

• Simplicity: Standard HTTP request — works everywhere, easy to implement, easy to cache.
• Predictable server load: Requests arrive at a fixed rate, making capacity planning straightforward.
• Wasteful: Most requests return nothing, burning server CPU, network bandwidth, and client battery.
• Latency: On average, the user waits `interval / 2` time after an event before seeing it. At 5-second intervals, average latency is 2.5 seconds.

Long Polling

Long polling improves on short polling by having the server hold the request open until new data is available. The client sends a request; the server doesn't respond until it has something to send or a timeout (typically 30-60 seconds) expires. When the response arrives, the client immediately sends another request.

// Long polling client implementation
async function longPoll(userId, lastEventId = null) {
  while (true) {
    try {
      const url = new URL(`/api/events/${userId}`);
      if (lastEventId) url.searchParams.set('since', lastEventId);

      const response = await fetch(url, {
        signal: AbortSignal.timeout(65000) // Slightly over server timeout
      });

      if (response.ok) {
        const data = await response.json();
        if (data.events.length > 0) {
          lastEventId = data.events.at(-1).id;
          processEvents(data.events);
        }
        // Immediately reconnect
      }
    } catch (err) {
      if (err.name !== 'TimeoutError') {
        // Exponential backoff on real errors
        await sleep(Math.min(retries++ * 1000, 30000));
      }
    }
  }
}

Comparing All Approaches

Decision Framework

Use this mental model when choosing a real-time mechanism in an interview:

1. Do you need sub-second bidirectional communication? → WebSocket (gaming, collaborative editing, live chat with user input).
2. Is it server-to-client only with near-real-time needs? → SSE (notifications, live dashboards, order tracking).
3. Are WebSockets/SSE blocked or unsupported? → Long polling (enterprise environments, legacy systems).
4. Is the update frequency low (> 1 minute)? → Short polling (build status, email sync, weather updates).
5. Is push completely overkill? → Webhooks + pull on demand (third-party integrations, batch jobs).