How the interviewer opens it
“Design a service that shows whether users are online, idle, or offline across multiple devices. Keep viewers informed as users connect and disconnect.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Population and connections
- Status rules
- Heartbeats and disconnect detection
- Subscriptions and audience size
- Read and write mix
- Latency
- Consistency and freshness
- Durability
- Authorization
- Deployment and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Accept device connections, heartbeats, activity reports, and disconnects
- Determine one user status from all current device sessions
- Read the current status of multiple users
- Send status changes and freshness information to authorized viewers
Usually out of scope
- Chat messages and message delivery
- Typing indicators
- Presence history and last-seen time
- Mobile push notifications
- The contact permission service
What interviewers ask about
- Status across devices
- A quiet device can remain connected. Delayed events from an old connection can corrupt a new connection's state.
- Status at subscription time
- A viewer needs a snapshot and later changes without a gap. Retries and owner changes can deliver older states after newer states.
- Large viewer audiences
- One status change can reach 100,000 viewers. Routine heartbeat and freshness traffic can exceed actual status traffic.
- Freshness during failures
- An unchanged status produces no change event. A live viewer connection does not prove that the state owner or update path still works.
Common mistakes
- A single user flag lets one device disconnect hide another active device.
- Heartbeats keep a user online forever, even without user input.
- Delayed disconnects or expiry tasks delete a newer device session.
- The traffic estimate omits subscription edges, recipient deliveries, or freshness renewals.
- Snapshot requests leave a gap before status updates begin.
- A shared failure creates false offline states or leaves old states fresh forever.
The bar by level
- Mid-level (L4/E4)
- Defines device and user states. Builds a heartbeat and expiry flow. Supports multiple devices and authorized subscriptions. Explains when clients mark status stale.
- Senior (L5/E5)
- Handles stale session events, expiry races, snapshot gaps, and duplicate updates. Calculates delivery load and bounds queues. Defines freshness deadlines across source and path failures.
- Staff (L6+/E6+)
- Defines quorum-backed ownership and complete freshness proofs across failover. Budgets subscription memory and recovery capacity. Limits failure scope and sets explicit overload behavior.