Loading system design…
Loading system design...
Design a messaging platform like WhatsApp that supports 1-on-1 and group messaging with end-to-end encryption (Signal Protocol), media sharing, voice/video calls (WebRTC), ephemeral Stories, presence indicators, and multi-device sync — all at a scale of 2 billion users sending 100 billion messages per day.
| Metric | Value |
|---|---|
| Total users | 2 billion |
| Daily active users (DAU) | 1 billion |
| Messages sent per day | 100 billion |
| Peak messages per second | ~5 million |
| Concurrent WebSocket connections | ~500 million |
| Group chats | 1 billion+ (up to 1,024 members each) |
| Media messages per day | 7 billion (images, videos, voice notes, documents) |
| Voice/video calls per day | 2 billion minutes |
| Average message size | 200 bytes (encrypted payload) |
| Offline messages queued | ~10 billion at any given time |
| Chat servers (Erlang) | ~10,000 (each: 500K connections) |
1-on-1 messaging: send text, emoji, and link-preview messages between two users in real-time with < 200ms latency when both are online
Group messaging: create groups with up to 1,024 members; send messages visible to all group members; group admin controls (add/remove members, change group info)
End-to-end encryption (E2EE): all messages encrypted on sender's device and decrypted only on recipient's device; server CANNOT read message content (Signal Protocol)
Offline message delivery: if recipient is offline, store encrypted messages on server; deliver when recipient comes online; messages persist until delivered (store-and-forward)
Message receipts: single tick (sent to server), double tick (delivered to recipient's device), blue ticks (recipient read the message); timestamps for each
Media sharing: send images, videos (up to 2 GB), voice notes, documents, contacts, and location; media uploaded to server, E2EE encrypted, recipient downloads on demand
Voice and video calls: 1-on-1 and group calls (up to 32 participants); real-time audio/video with < 300ms latency; WebRTC with TURN/STUN for NAT traversal
Status/Stories: 24-hour ephemeral updates (text, image, video) visible to contacts; view tracking (who viewed your status); auto-delete after 24 hours
Online/last seen/typing indicators: show when a contact is online, their last seen timestamp, and a 'typing...' indicator during active composition
Multi-device support: use WhatsApp on up to 4 linked devices (phone + web + desktop + tablet) simultaneously; messages synced across all devices in real-time without phone needing to be online
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In