Managing user presence with reconnection grace periods

WHAT THIS TESTS Whether the candidate can build reliable real-time presence on top of inherently unreliable connections, a common source of flickering online/offline bugs.

A GOOD ANSWER COVERS Real-time libraries like Socket.IO emit connect and disconnect events and run a heartbeat (ping/pong) to detect dead connections. The key insight is that a disconnect does not equal the user leaving; mobile networks, tab sleeps, and brief outages cause transient drops, and clients auto-reconnect. So on disconnect, start a grace timer of a few seconds to tens of seconds rather than immediately marking offline. If the same user reconnects within the window, cancel the timer and keep them online. Track presence keyed on a stable identifier such as the authenticated user id, not the ephemeral socket id, because a reconnect issues a new socket id. In a multi-instance deployment, store presence and timers in a shared store like Redis (with the Socket.IO Redis adapter) so any server can see the user's state and broadcast changes.

COMMON WRONG ANSWERS Marking a user offline the moment the socket drops, causing presence to flicker. Keying presence to the socket id, so each reconnect looks like a brand-new session. Keeping state only in process memory, which breaks across multiple instances behind a load balancer.

LIKELY FOLLOW-UPS How long should the grace period be? How do you handle multiple devices for one user? How do you reconcile state after a server restart? How does Redis pub/sub broadcast presence changes across nodes?

ONE CONCRETE EXAMPLE A user rides an elevator and loses signal for eight seconds. The server gets a disconnect but starts a fifteen-second grace timer keyed to userId. The client reconnects with a new socket id, the server finds the pending timer for that userId, cancels it, and the user never appears offline. If the user had closed the tab instead, no reconnect arrives, the timer fires, and presence flips to offline.