Presence and online status

The idea

That little green dot in a chat app says a friend is here right now. But the server can't constantly ask "are you still there?" of every user — so instead each client quietly sends a small heartbeat message every few seconds, just to say "still here".

The presence service marks you online the moment a heartbeat lands, and starts a countdown — a time-to-live (TTL). Each new heartbeat resets that countdown. If the countdown ever hits zero, your heartbeats have stopped, so you're flipped to offline. Offline is detected by absence, not by a goodbye message — because crashes and dropped networks never get to say goodbye.

See it work

How it works

The trick is to store presence as a key with an expiry. Every heartbeat re-writes the key with a fresh TTL. You never write a "logout" — you just stop refreshing, and the key disappears on its own. Reading status becomes "does the key still exist?".

// --- server: on each heartbeat ---
const HEARTBEAT = 10;          // client beats every 10s
const TTL = 30;                // tolerate ~3 missed beats

async function onHeartbeat(userId) {
  const key = `presence:${userId}`;
  const wasOnline = await redis.exists(key);
  // SETEX writes the value AND a fresh expiry in one atomic op
  await redis.setex(key, TTL, "online");
  if (!wasOnline) publish("presence-change", { userId, online: true });
}

// --- server: reading status is just "does the key exist?" ---
async function isOnline(userId) {
  return (await redis.exists(`presence:${userId}`)) === 1;
}

// Offline is detected by ABSENCE: when the key expires, a keyspace
// notification fires the transition — no goodbye message required.
redis.on("expired", (key) => {
  const userId = key.split(":")[1];
  publish("presence-change", { userId, online: false });
});

// --- client: send a heartbeat on an interval ---
setInterval(() => {
  // jitter so a million clients don't all beat on the same second
  const jitter = Math.random() * 1000;
  setTimeout(() => sendHeartbeat(myUserId), jitter);
}, HEARTBEAT * 1000);

On every status flip — online → offline or back — the service publishes a presence-change event so friends' clients can update their green dots. Note the transition is published only on a change, not on every heartbeat.

Cost and trade-offs

Watch out for

• TTL equal to the heartbeat interval: a single lost packet makes a live user flicker offline. Make the TTL roughly 3× the interval so one or two missed beats are tolerated.
• Relying on a clean disconnect for offline: crashes, killed apps, and dead networks never send a logout. Treat the goodbye message as a fast-path optimization, never the source of truth — TTL expiry is.
• Every client beating on the same second: synchronized heartbeats create a "thundering herd" spike each interval. Add per-client random jitter so the load spreads evenly.
• Heartbeat on a different channel than the real connection: if the heartbeat path is healthy but the actual chat socket is dead, you report someone online who can't receive messages. Beat over the same connection users rely on.
• Fan-out of presence-change events: a single user with a huge friend list can trigger thousands of "they're online" pushes. This fan-out, not the heartbeats, is usually the real scaling cost.

Worked example

Say you have 1,000,000 users, each heartbeating every 10 seconds. That's 1,000,000 / 10 = 100,000 heartbeats per second hitting the presence service — steady, write-heavy load you must size for.

With a TTL of 30 seconds, the service tolerates 2 missed beats before declaring someone offline; the third missed beat lets the key expire. Worst-case detection lag is therefore about 30 seconds.

Now double the interval to 20 seconds: traffic halves to 50,000 beats/s — a real saving — but to keep tolerating 2 missed beats you raise the TTL to 60s, so worst-case "this user went offline" now takes up to a minute to notice. That single knob trades server cost against how fresh the green dot feels.