Showing which users are currently online seems trivial and is one of the most expensive features in a chat product. Explain.

What the interviewer is testing

Whether you can recognise a quadratic fan-out problem hiding behind a simple feature.

Why it is expensive

Presence changes constantly and is watched by many. Every connect, disconnect, idle transition and return produces a state change, and each change must reach everyone who can see that user.

In a workspace of n users where everyone can see everyone, a single presence change is n notifications, and n users changing state is n² work. For a large organisation with people connecting and disconnecting throughout the day, this dwarfs actual message traffic.

The second cost is that presence is inherently uncacheable at long TTL — its value is that it is current — so it defeats the usual optimisation.

The mitigations

Only track what is being watched. A user's presence matters only to people currently looking at a view that displays it. Subscribing to presence for the users visible on screen, rather than for the whole workspace, reduces the fan-out by orders of magnitude. This is the single largest saving.

Coalesce and batch. Presence changes are not urgent. Aggregating changes over a few seconds and sending one batched update collapses a burst into one message.

Reduce the state space. Online, away, offline — not a precise last-seen timestamp, which changes continuously and forces an update on every change.

Accept staleness. Presence being a few seconds out of date is imperceptible. Treating it as eventually consistent removes any need for coordination.

Derive rather than report. Presence can be inferred from connection state at the connection server rather than requiring clients to send heartbeats, which halves the traffic.

What a strong answer adds

Questioning the requirement. Presence is frequently a product decision made without knowing the cost, and for many products a coarser signal — active today, or nothing at all — delivers most of the user value at a fraction of the expense. Presenting that trade to product is more useful than engineering an expensive feature well.

And the general lesson: any feature where every user's state is visible to every other user is quadratic, and it needs a subscription model rather than a broadcast model.

Common weak answers

Caching presence, which conflicts with its purpose. Scaling the presence service without reducing the fan-out.