Requirements

Functional Requirements:

• support statused (online/idle/offline)
• save presence per session/device (online if any device is online), idle if

so support multi-device aggregation

• Clients Holds persistent connection (WebSockets) to recieve real-time updates and set heart beats to report liveness
• support collecting status of all my friends
• support 'last seen'
• marking as "Do not disturb"

Non-Functional Requirements:

• hundreds of milions of users (scalability)
• huge hearbeat throughput
• availability

Capacity Estimation

• 100M DAU, peak online concurrency ~50M users (50% of DAU online at peak)
• ~2 devices per user (phone + laptop/desktop) → ~100M concurrent persistent connections to your gateway/WebSocket tier. That number drives your connection-management design more than DAU does.

• Heartbeats: 50M online users ÷ 30s interval ≈ ~1.7M writes/sec — this is my dominant write volume

Reads: batch presence lookups when apps open — ~100M DAU × ~5 opens/day, each fetching ~200 friends ≈ ~500K–1M lookup-equivalents/se

• So roughly ~2:1 writes-to-reads, which is unusual — most systems are read-heavy. The nuance interviewers like: the expensive reads are the fan-out deliveries (each presence change pushed to watchers), not the simple lookups.
• Fan-out: users transition state ~10×/day → 50M online users × 10 ≈ 500M transitions/day ≈ ~6K state-change events/sec. Each pushes to the watcher's online friends (~100 of ~200 typical) → ~600K delivery messages/sec through the real-time tier. This is what actually stresses the push/fan-out path, not the 1.7M heartbeats (which are cheap to absorb).

Storage

• Real-time state (status, last_seen, version, device count) in Redis: 100M users × ~200 bytes ≈ ~20–40 GB — fits in memory comfortably
• Historical log: ~1–2B status-transition events/day × ~100 bytes ≈ ~150–200 GB/day raw — you must aggregate (hourly summaries, short retention) or it becomes petabytes in months

API Design

REST for snapshot queries

WebSocket for real-time plaan

/heartbeat API (every 30sec.)

• presence events (server pushes friend state changes to watchers)
• subscribe/unsubsribe - managing who you are watching

High-Level Design

Clients publish their statuses via WatchingService (deviceID, status, time).

WatchingService publishes status changes to Hub (PresenceEvents WebSocket)

AvailabilityService monitor is pulling data from PresenctEvents to check who is online and what is their status

. In a real system, a user's Wi-Fi blips for 3 seconds and their presence would show offline→online→offline, spamming every watcher with events. You need a TTL/grace buffer on the server: don't declare offline until the heartbeat misses for ~60s. This is arguably the core trick of presence systems.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

 Presence Service — the liveness gate (highest value, pick this one)

• Algorithm: per-device TTL key in Redis (device:{userId}:{deviceId} with ~60s expiry, refreshed on each heartbeat). Offline fires only when the TTL expires — no offline event, no push.
• Multi-device: keep a device_count per user (INCR on connect, DECR on TTL expire/disconnect). User-level offline only when count hits 0 — so a phone dying doesn't flip the laptop user offline.
• Scale: 1.7M heartbeat writes/sec → shard Redis by userId; heartbeats are idempotent SETs, so they spread cheaply.
• Trade-off: grace window (60s) vs. accuracy (last-seen is up to 60s stale). Tune per platform — mobile gets a longer window than desktop.

2. Fan-out Hub — delivery to watchers

• Per-user topic (presence:{userId}) that watchers subscribe to; updates routed only to subscribers.
• Celebrity mitigation (major, easily missed): a celebrity's status change fans out to millions. Mitigate with partitioned fan-out workers, batching, or throttling fan-out per publisher.

3. WebSocket Gateway — connection lifecycle, heartbeats, and disconnects; scale-out via connection hash.

Plus a minor line: transitions append to Kafka for analytics — off the hot path.