Who's around — presence dots for a workplace chat app

Every workplace chat app has one: a small dot beside a name, green when someone is around, amber when they have stepped into a meeting, grey when they are gone for the day. Nobody notices it until it lies — a colleague looks green, you send them something urgent, and an hour later you learn their laptop died before lunch. You are building the realtime layer that keeps that dot honest: the open connection, the change, the fan-out to a team, and — this is the part that actually bites — what happens when nobody tells you a connection is gone.

What the dot has to do

• An employee opens the chat app and keeps a connection to the gateway fleet open for as long as the app stays open.
• The instant a teammate's dot changes, everyone else on their team who has the app open sees it, over their own connection.
• Opening the app shows a whole team's current dots at once, not a blank screen that slowly fills in with whatever changes happen next.
• While a connection is open and nothing has changed, the client still checks in quietly every so often, so the system can tell "still here, just quiet" apart from "gone."

Why a clean goodbye can't be the whole story

Most of the time a status change is a deliberate, well-behaved event: someone opens their laptop, joins a call, logs off at the end of the day. But a real connection also disappears the ugly way — a battery dies, a train enters a tunnel, an app is force-quit. None of those send a final "I'm offline" message. If the only thing that ever updates a dot is an explicit change, a colleague who vanished mid-morning stays green until the end of time, or until someone happens to notice and asks IT.

The fix has to live in the store that holds each teammate's dot, not in the client that just went dark. Give every entry a lifespan: something that only a live connection keeps renewing, whether by an actual dot change or by one of its quiet check-ins. Let it run out, and the entry is gone on its own — no cron job, no support ticket, no one watching for it. The presence service writes every change and every renewal straight into the store and stamps the entry's expiry as it writes it; the store holds the only copy of a dot, with no database behind it.

The numbers

• About 400,000 employees keep the app open through a working day, on teams of exactly 50 — a number the product side has fixed, not something you get to resize.
• One employee's own dot changes on average once every 200 seconds. Near the top of the hour, when a run of meetings ends together, that climbs to roughly four times the rate for about thirty seconds.
• A connection that has not sent a change quietly checks in every 20 seconds. The gateway answers each check-in on the socket and passes them on as batched renewals, so they add almost nothing to the traffic below it.
• Writing one frame to one socket costs about 20 µs of gateway CPU; accepting a new connection (TLS and sign-in) costs about 2 ms; recording a change in the presence service costs about 1 ms. Set frame_us, handshake_ms and write_cpu_ms to match.
• Most dot changes arrive on a connection the gateway has only just accepted — a laptop waking after a meeting, the app reopened — so size each change as a handshake as well as its fan-out.

What good looks like

A dot change reaches a teammate's socket within 300 ms at p99, and at most 1 update in 100 fails to be delivered — looser than a chat message's budget, because the next change or the next check-in repairs a miss. Both hold through a meeting turnover as well as on an ordinary quiet afternoon.

Separately, and just as firmly: a teammate who goes quiet for a single missed check-in must not flicker offline — that is an ordinary lag, not a disappearance — but one who is truly gone must not be shown as present for more than a minute after the fact.

Where to start

Size the gateways first, the way you would for any broadcast — but notice how little the fan-out costs at a team of 50 next to a room full of strangers, and how much of each change is the handshake that comes with it. Then size the presence service for a turnover. Once the traffic math is out of the way, work out what keeps an entry alive in the store, what lets it go, and how those two numbers box in the one setting that actually matters here: the expiry the presence service stamps on every entry it writes, its cache_ttl_s.

Out of scope: how an employee signs in and is matched to their teams, custom status text, and the chat feature itself.