Online Indicator

Green dot for contacts. Mind the N² watch problem. Approximate by design — never quote presence more precisely than reality.

SavedSaved on this device

The problem

Green dot for contacts. Mind the N² watch problem. Approximate by design — never quote presence more precisely than reality.

Build the Online Indicator — the green dot next to every contact's name in your chat app, plus the "last seen 12 min ago" line that follows it. Used by Slack, Discord, WhatsApp, Messenger, Teams, Instagram, LinkedIn — every product with a contact list. Sounds simple. It is not.

Three things make this problem hard at production scale:

N² watch problem. Every user is both a presence publisher and a presence subscriber. At 1B DAU each with ~500 contacts, the naive eager-broadcast design produces 500B subscription edges and ~250M frames/s of fanout. Physically impossible.
Ephemeral state at billion-user RAM scale. ~500M concurrent online users × ~100 B/record = ~50 GB per region — hot, in RAM, all the time, fully replicated.
Approximate by design. The product line "last seen 12 min ago" is a privacy + capacity invariant, not a UX choice. Quoting last_seen precisely (±1 s) leaks PII and forces hot-path persistence; quantizing to ±60 s solves both.

The architecture is the canonical Discord/Slack/WhatsApp shape: a long-lived WebSocket to a stateful gateway, a sharded actor tier holding hot presence in RAM, a separate fanout relay tier as the N² solver, an ephemeral cache for cross-shard reads, a durable spine for the audit trail, and a quantized last-seen store for the offline case.

Reading: How Discord Scaled Elixir to 5,000,000 Concurrent Users (discord.com/blog, 2017) · How Discord Handles Push Request Bursts with Elixir's GenStage (discord.com/blog) · How Discord Stores Trillions of Messages (discord.com/blog, 2023) · Slack's Disasterpiece Theater — Approachable Chaos Engineering (slack.engineering) · Slack's Outage on January 4th 2021 (slack.engineering) · Slack's Incident on 2-22-22 (slack.engineering) · Rick Reed — WhatsApp Scaling, Erlang Factory 2014 (erlang-factory.com) · WhatsApp — Giving You More Control Over Your Privacy (blog.whatsapp.com, 2012/2018) · Facebook TAO: A Distributed Data Store for the Social Graph (USENIX ATC 2013) · Google SRE Workbook — Alerting on SLOs (burn-rate alerts) · AWS Builders' Library — Timeouts, Retries and Backoff with Jitter · Cloudflare 2020-07-17 BGP-withdrawal post-mortem (blog.cloudflare.com) · Datadog 2023-03-08 multi-region connectivity outage retro (datadoghq.com)

viewport-bounded subscription (the N² solver)
lazy fanout vs eager broadcast
presence liveness economics (in-memory sweeper at heartbeat × 2; long backstop TTL on the cache key)
event-sourced spine: durable log first, cache + relay as projections
approximate by design (±60s last_seen buckets)
privacy as first-class (everyone / contacts / nobody / invisible)
fail closed on 'unknown' — never render fake online
broadcast amplification storm on region heal
WS reconnect storm tolerance

01Clarifications

What would you ask before drawing a single box?

Ambiguity you would resolve with the interviewer: scope, scale, who uses it, what counts as done.

About Online Indicator

Green dot for contacts. Mind the N² watch problem. Approximate by design — never quote presence more precisely than reality.

Difficulty: intermediate
Time: about 45 minutes
Stages: 10
Topic: Real-Time: Chat, Presence & Live Updates

How this problem is worked

Ten stages, from the questions you would ask an interviewer to the trade-offs you would defend. Each asks one question, and the simulator runs the architecture you draw against the requirements you wrote.

01ClarificationsWhat would you ask before drawing a single box?
02Functional reqsWhat must this system actually do?
03Non-functionalWhat must it promise about speed, uptime and correctness?
04Capacity estimationHow much load and data does this have to hold?
05API designWhat does the outside world call, and what comes back?
06Data modelWhat gets stored, and what is it looked up by?
07Use-case breakdownHow does each requirement actually get served?
08High-level designWhich components handle a request, and in what order?
09Deep divesWhich part breaks first, and what do you do about it?
10Trade-offsWhat did this design cost, and what breaks at 10×?

Primary sources for this problem

How Discord Scaled Elixir to 5,000,000 Concurrent Users (discord.com/blog, 2017)
How Discord Handles Push Request Bursts with Elixir's GenStage (discord.com/blog)
How Discord Stores Trillions of Messages (discord.com/blog, 2023)
Slack's Disasterpiece Theater — Approachable Chaos Engineering (slack.engineering)
Slack's Outage on January 4th 2021 (slack.engineering)
Slack's Incident on 2-22-22 (slack.engineering)
Rick Reed — WhatsApp Scaling, Erlang Factory 2014 (erlang-factory.com)
WhatsApp — Giving You More Control Over Your Privacy (blog.whatsapp.com, 2012/2018)
Facebook TAO: A Distributed Data Store for the Social Graph (USENIX ATC 2013)
Google SRE Workbook — Alerting on SLOs (burn-rate alerts)
AWS Builders' Library — Timeouts, Retries and Backoff with Jitter
Cloudflare 2020-07-17 BGP-withdrawal post-mortem (blog.cloudflare.com)
Datadog 2023-03-08 multi-region connectivity outage retro (datadoghq.com)

More in Real-Time: Chat, Presence & Live Updates

Long-lived connections and the things you push down them — messages, cursors, green dots, scores, prices and bids.

Browse the full problem catalog, or see what the simulator does and does not model.