Short polling for presence

The idea

A presence system shows which users are online — the little green dot next to a name. With short polling, each client sends an HTTP request every few seconds asking “is anything different?” The server answers immediately with the current state and the connection closes. Nobody holds anything open.

It is simple and firewall-friendly: it is just normal request/response, so it works anywhere a web page loads. But it scales poorly. Most answers are empty (“no change”), the freshest a peer can ever be is one poll interval behind reality, and total load grows with clients × poll frequency. Push models (long-poll, SSE, WebSocket) flip this: the server speaks the moment something changes.

See it work

How it works

The client side is a plain loop on a timer: ask, render, wait, repeat. The server has no memory of who is listening — it just answers whatever is true at the instant the request lands.

// Each client runs this independently.
const INTERVAL = 5000;            // ms — the poll period
let lastSeen = null;              // version/etag of the last state we drew

function pollPresence() {
  fetch('/presence?since=' + lastSeen)
    .then(r => r.json())
    .then(state => {
      if (state.changed) {        // server says something moved
        lastSeen = state.version;
        renderRoster(state.online); // redraw the green dots
      }
      // else: empty response, nothing to do — a wasted round trip
    })
    .catch(() => {/* coach note: back off & retry, don't hammer */});
}

// Add jitter so 10k clients don't all fire on the same tick.
const jitter = Math.random() * 1000;
setInterval(pollPresence, INTERVAL + jitter);

Trade-offs

Watch out for

• Thundering herd. If every client starts its timer at the same moment (page load, top of the minute), polls arrive in synchronized waves that spike the server instead of spreading out.
• No jitter. Add a small random offset to each interval so the herd disperses; without it, retries and reconnects re-synchronize the spikes.
• Tuning the interval. Shorter means fresher but heavier; longer means cheaper but staler. The interval is your latency budget — choose it deliberately.
• Empty responses dominate. When presence rarely changes, almost every round trip carries nothing new. That bandwidth and CPU is pure overhead.
• Staleness confuses users. Someone can look online for up to a full interval after they leave. Make the freshness window explicit, or move to push when it matters.
• Know the threshold. Past a scale or freshness line, switch to long-poll, SSE, or WebSocket so the server notifies on change instead of being asked.

Worked example

Say you have 500 users in a room and a 5 second poll interval. Each client fires 1 request every 5s, so the room generates 500 / 5 = 100 presence requests per second — ~360,000 per hour — whether or not anyone’s status actually changed.

Now suppose presence changes only a handful of times a minute. The overwhelming majority of those 100 requests/second come back empty: the “wasted polls” tally in the animation above is the whole room in miniature. And when a user does go offline, peers keep showing them online until their next poll — a detection lag of up to the full 5 second interval. A push model would close that gap to roughly 0 ms and send almost no empty traffic, at the cost of holding open connections and more moving parts.

Check yourself