Loading...
Requirements
Functional
- Track online / idle / offline + last seen
- Multi-device: online if any device is active
- Authorized viewers (e.g., managers) can view + subscribe to changes
- Real-time push to subscribers
- User-set status overrides (DND, appear offline)
Non-functional
- Low latency: Must handle 100M+ concurrent sessions and ~5M presence events/sec.
- HA, scalability
- Grace window / flapping tolerance
- Auth + authorization
Capacity Estimation
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
API Design
syntax = "proto3";
package presence.v1;
service PresenceService {
rpc Connect(stream PresenceClientEvent)
returns (stream PresenceServerEvent);
rpc GetPresence(GetPresenceRequest)
returns (GetPresenceResponse);
rpc GetPresenceBatch(GetPresenceBatchRequest)
returns (GetPresenceBatchResponse);
}
message PresenceClientEvent {
string user_id = 1;
string connection_id = 2;
ClientEventType event_type = 3;
int64 timestamp = 4;
}
enum ClientEventType {
CLIENT_EVENT_TYPE_UNSPECIFIED = 0;
CONNECTED = 1;
ACTIVITY = 2;
DISCONNECTED = 3;
HEARTBEAT = 4;
}
message PresenceServerEvent {
string user_id = 1;
PresenceStatus status = 2;
int64 last_activity = 3;
}
enum PresenceStatus {
PRESENCE_STATUS_UNSPECIFIED = 0;
ONLINE = 1;
IDLE = 2;
OFFLINE = 3;
}
message GetPresenceRequest {
string user_id = 1;
}
message GetPresenceResponse {
string user_id = 1;
PresenceStatus status = 2;
int64 last_activity = 3;
}
message GetPresenceBatchRequest {
repeated string user_ids = 1;
}
message GetPresenceBatchResponse {
repeated UserPresence presences = 1;
}
message UserPresence {
string user_id = 1;
PresenceStatus status = 2;
int64 last_activity = 3;
}
High-Level Design
DNS → Routes users to the Presence Service entry point.
CDN → Serves static web assets close to users; not used for live presence traffic.
WAF → Blocks malicious or suspicious requests before they reach the application.
DDoS Protection → Protects the service from massive malicious traffic spikes.
Firewall / Security Groups → Controls which network traffic is allowed into and between components.
Load Balancer → Distributes persistent user connections across Presence Service containers.
Containers → Run the Presence Service and scale horizontally as concurrent users increase.
Redis Cluster → Stores ONLINE/IDLE/OFFLINE, heartbeat and TTL in memory for very low-latency reads/writes.
Pub/Sub → Broadcasts presence changes so interested components can react asynchronously in real time.
Background Workers → Consume presence events and perform asynchronous processing without blocking the live connection.
NoSQL Database → Persists durable presence information such as last_seen without receiving every heartbeat.
Multi-AZ → Keeps the service available if an entire Availability Zone fails.
Sharding → Distributes users/data across nodes so the system can scale.
Replicas → Keep copies of data so another node can take over after a failure.
Hashing (userId) → Determines which shard owns a user's presence data.
Exponential Backoff + Jitter → Spreads reconnection attempts after failures to prevent millions of clients from overwhelming the service at once.
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
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.