Long Polling & SSE

Try it: long poll cycles versus one SSE stream

Publish an event and advance ticks. Count how many HTTP requests long polling spends compared with a single SSE connection.

What actually happens

How to choose

What actually happens with SSE replay

sequenceDiagram
    participant Client
    participant Proxy
    participant Stream as Connection server
    participant Log as Event log

    Client->>Proxy: GET /events with Last-Event-ID 42
    Proxy->>Stream: Forward, buffering off
    Stream->>Log: Read events after 42
    Log-->>Stream: Events 43..50
    Stream-->>Client: Replay 43..50, then live stream
    Stream-->>Client: Heartbeat every 25s

How SSE works: the two things you must get right

The diagram above shows a healthy replay end to end. The protocol handles parsing and reconnecting for you; the two things below are what it leaves to you, and they are the beats interviewers listen for. Say them in product language, then deepen if asked.

Comparison of realtime techniques

With the mechanics in hand, here is how the four options line up on direction, latency feel, and how hard the infrastructure is to run.

When to use each

The same trade-offs, applied to concrete products: match the pattern to whether clients mostly consume, occasionally command, or need gaming-grade two-way chatter.

How to choose WebSocket, SSE, or polling

Long polling deep dive

A long-poll response ends after an event or timeout, and the client immediately issues another request with its last received position. The next request can reuse the existing HTTP connection, so a new request does not inherently mean a new TCP and TLS handshake. Events produced between the response and the next request must remain available for replay; keeping a request open alone does not prevent this gap.

The math above sizes the traffic; now look closely at the older of the two HTTP tricks. Long polling holds a request open until news arrives or a timer fires, approximating push with plain request/response.

# Server (async handler)
async def poll(request):
    user_id = request.user.id
    timeout = 30  # seconds

    # Wait for new data or timeout
    data = await message_queue.get(
        user_id, timeout=timeout
    )

    if data:
        return JsonResponse(data)
    return HttpResponse(status=204)

# Client (JavaScript)
async function longPoll() {
    const res = await fetch('/poll');
    if (res.status === 200) {
        handleMessage(await res.json());
    }
    longPoll(); // immediately re-poll
}

Long polling at scale (2008–2014). This simple loop carried real load before WebSockets were ubiquitous. Large social apps served hundreds of millions of concurrent chat users with long polling. Each user held one open HTTP connection, async channel servers managed millions of held connections per machine, and messages landed within 100–300ms. They eventually migrated to mobile messaging protocols and WebSockets for web, but long polling proved that simple techniques can scale far.

Server-Sent Events deep dive

Long polling fakes push with repeated requests; SSE gets there with a single response, as you saw in What actually happens. This section shows exactly what that looks like on the wire, then in code, then in products.

GET /events HTTP/1.1
Host: api.example.com
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream    ← this is the magic header
Cache-Control: no-cache            ← don't buffer events
Connection: keep-alive             ← keep the pipe open

event: price_update
id: 1001
retry: 3000
data: {"symbol": "AAPL", "price": 189.42}

event: price_update                ← server keeps writing...
id: 1002
data: {"symbol": "GOOG", "price": 141.80}

                                   ← connection stays open forever

HTTP Response Headers:
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

Event Stream Format:
event: message           ← named event type (optional)
id: 12345                ← event ID for reconnection tracking
retry: 3000              ← reconnect delay in ms
data: {"user": "alice"}  ← payload (can be multi-line)

event: notification
id: 12346
data: {"type": "like", "count": 42}
                                   ← double newline = event boundary

Worked example: a stock ticker over SSE

The headers and fields above are all a real ticker needs. The JavaScript server below writes a price event every second; the browser subscribes with EventSource and gets reconnection for free.

app.get('/stocks', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  // Send price every second
  const interval = setInterval(() => {
    const data = {
      symbol: 'AAPL',
      price: (180 + Math.random() * 10).toFixed(2),
      time: new Date().toISOString()
    };
    res.write(`event: price\n`);
    res.write(`id: ${Date.now()}\n`);
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  }, 1000);

  req.on('close', () => clearInterval(interval));
});

const source = new EventSource('/stocks');

source.addEventListener('price', (e) => {
  const { symbol, price, time } = JSON.parse(e.data);
  document.getElementById('ticker').textContent =
    `${symbol}: $${price}`;
});

// Auto-reconnect is FREE
source.onerror = () => {
  console.log('Connection lost, reconnecting...');
  // Browser auto-reconnects in 3s (or retry: value)
  // Sends Last-Event-ID header automatically
};

// Clean up
window.addEventListener('beforeunload', () => {
  source.close();
});

# Python (async web framework)
async def event_stream(user_id):
    last_id = request.headers.get(
        'Last-Event-ID', 0)
    async for event in subscribe(
        user_id, after=last_id):
        yield (
            f"event: {event.type}\n"
            f"id: {event.id}\n"
            f"data: {event.json()}\n\n"
        )

return StreamingResponse(
    event_stream(user_id),
    media_type="text/event-stream"
)

// Browser JavaScript
const source = new EventSource(
    '/events?userId=123'
);

source.addEventListener('message',
    (e) => {
        const data = JSON.parse(e.data);
        displayMessage(data);
    });

source.addEventListener('notification',
    (e) => {
        showNotification(JSON.parse(e.data));
    });

source.onerror = () => {
    // Auto-reconnects with Last-Event-ID
    console.log('Reconnecting...');
};

Where SSE shows up in products

The ticker is one instance of a pattern you meet everywhere the server has news and the client mostly watches.

POST /v1/chat/completions
{"model":"gpt-4","stream":true,...}

Response (SSE stream):
data: {"choices":[{"delta":{"content":"Hello"}}]}
data: {"choices":[{"delta":{"content":" world"}}]}
data: {"choices":[{"delta":{"content":"!"}}]}
data: [DONE]

What breaks in production

Each stream needs a bounded outgoing buffer. If a client reads slower than the event producer, backpressure eventually reaches the server or its buffer grows without limit. For durable logs, disconnect the client and let it resume later; for a dashboard, consider replacing older queued snapshots with the newest state. Heartbeats should occur before intermediary idle timeouts, while reconnects should use randomized backoff to spread recovery load.

Everything so far assumed a healthy connection. In production, long-lived HTTP responses get severed, held connections eat memory, and reconnects arrive in waves. This card collects those failures and the questions that surface them early.

// Server: handling reconnection with Last-Event-ID
app.get('/events', async (req, res) => {
  const lastId = req.headers['last-event-id'] || '0';

  // 1. Replay missed events from storage
  const missed = await db.query(
    'SELECT * FROM events WHERE id > ? ORDER BY id', [lastId]
  );
  for (const event of missed) {
    res.write(`id: ${event.id}\ndata: ${event.data}\n\n`);
  }

  // 2. Then stream live events
  const subscriber = pubsub.subscribe('events', (event) => {
    res.write(`id: ${event.id}\ndata: ${event.data}\n\n`);
  });

  req.on('close', () => pubsub.unsubscribe(subscriber));
});

Wrap-up