OneNoughtOne
0/273
Loading content...
Read aloud is unavailable in this browser.
WhatsApp processes over 100 billion messages daily, serving more than 2 billion active users across virtually every country on Earth. When you press 'send' on a message, an extraordinarily sophisticated system springs into action—routing your message through a global network of servers, ensuring delivery even when recipients are offline, maintaining end-to-end encryption that not even WhatsApp itself can break, and doing all of this in typically under one second.
Designing such a system represents one of the most challenging problems in distributed systems engineering. Unlike many applications where 'good enough' performance suffices, messaging systems must satisfy stringent requirements across multiple dimensions simultaneously: real-time latency for interactive conversations, perfect reliability where losing even one message is unacceptable, massive scalability to handle billions of concurrent users, and uncompromising security to protect private communications.
This module will take you through the complete system design of a WhatsApp-like messaging platform. We begin where every good system design must: with a rigorous, exhaustive analysis of requirements.
By completing this page, you will understand how to systematically decompose messaging system requirements into functional capabilities, non-functional constraints, and scale parameters. You'll learn the critical questions that separate naive implementations from production-ready architectures, and you'll develop the analytical framework for approaching any real-time communication system design.
Before diving into requirements, we must understand what makes messaging systems fundamentally different from other distributed applications. A messaging system is not simply a database with a UI—it's a real-time communication fabric that must maintain the illusion of instantaneous, reliable delivery across billions of devices connected through unreliable networks.
The core challenges unique to messaging:
When tackling this problem in an interview, spend the first 5-7 minutes deeply exploring these challenges with your interviewer. This demonstrates systems thinking and ensures you're solving the right problem. The questions you ask reveal far more about your expertise than the solutions you provide.
Functional requirements define what the system must do. For a messaging system, we must be exhaustive—missing a core requirement leads to fundamental architectural flaws. Let's systematically enumerate every capability our messaging platform must provide.
Direct messaging between two users forms the foundation of any messaging platform. Let's decompose this seemingly simple feature:
| Requirement | Description | Complexity |
|---|---|---|
| Send text message | User A can send a text message (up to ~65,000 characters) to User B | Low |
| Receive text message | User B receives the message in real-time if online, or upon reconnection if offline | Medium |
| Message ordering | Messages in a conversation appear in the order they were sent, even across network partitions | High |
| Send media | Users can send images (up to 16MB compressed), videos (up to 2GB), documents, voice notes (up to 15 min), and location data | High |
| Message acknowledgment | System provides sent, delivered, and read receipts with timestamps | Medium |
| Message history | Users can scroll back through unlimited message history, loading older messages on demand | Medium |
| Delete for me/everyone | Users can delete messages locally or retract them for all participants within a time window | Medium |
| Edit messages | Users can edit sent messages within a time window, with edit history visible | Medium |
| Reply to specific message | Users can quote and reply to specific messages, maintaining threaded context | Low |
| Forward messages | Users can forward messages to other chats, with forwarding metadata preserved | Low |
Group chats introduce exponentially more complexity than 1:1 messaging. What seems like 'just sending to multiple people' creates intricate consistency and delivery challenges:
| Requirement | Description | Complexity |
|---|---|---|
| Create group | Any user can create a group with a name, icon, and description, inviting initial members | Low |
| Add members | Admins can add new members; system must sync full message history or from join point | High |
| Remove members | Admins can remove members; removed users lose access but retain prior messages locally | Medium |
| Leave group | Any member can leave; remaining members are notified | Low |
| Admin hierarchy | Groups support multiple admin levels with different permissions (add/remove members, change settings, etc.) | Medium |
| Group size limits | Support up to 1,024 members per group (WhatsApp's current limit), with graceful handling of fan-out | High |
| Message delivery to all | Every message must reach every group member, with appropriate retry logic for offline members | Very High |
| Consistent group membership view | All members must have consistent view of who is in the group, despite network partitions | Very High |
| Group settings | Admins can restrict who can send messages, change group info, or add members | Low |
| Disappearing messages | Groups can enable auto-delete for messages after configured time periods | Medium |
A single message in a 1,000-member group requires 999 deliveries. With 100 million active groups and each member posting 1 message/day, that's 100 trillion deliveries daily. This fan-out multiplier is why group messaging dominates architecture decisions.
While not the 'core' messaging feature, user management requirements significantly impact architecture. These requirements determine authentication flows, data storage patterns, and privacy mechanisms.
Contact discovery is a deceptively difficult problem. Users want to know which of their contacts are on the platform, but uploading your entire contact list to a server raises serious privacy concerns.
Approaches to contact discovery:
1234567891011121314151617181920
Approach 1: Plain Upload (Privacy-Poor)────────────────────────────────────────- Client uploads contacts: [+1234567890, +0987654321, ...]- Server returns registered matches- Problem: Server knows your entire social graph Approach 2: Hash-Based Matching (Better, but flawed)────────────────────────────────────────────────────- Client hashes contacts: [SHA256(+1234567890), ...]- Server matches against registered user hashes- Problem: Phone numbers have low entropy (~10^10 possible numbers) Server can precompute all hashes and reverse them Approach 3: Private Set Intersection (Privacy-Preserving)────────────────────────────────────────────────────────- Use cryptographic protocols where: • Client learns ONLY which contacts are registered • Server learns NOTHING about unregistered contacts- Examples: PSI using Diffie-Hellman or homomorphic encryption- Trade-off: Higher computational cost, but mathematically privateMentioning Private Set Intersection for contact discovery in an interview demonstrates security awareness beyond the obvious. It shows you've thought about privacy implications that many engineers overlook.
Understanding scale is critical because it determines nearly every architectural decision. A system for 1,000 users looks nothing like one for 1 billion. Let's establish WhatsApp-scale numbers and derive the implications:
| Metric | Value | Design Implication |
|---|---|---|
| Monthly Active Users (MAU) | 2 billion | Massive user database sharding required |
| Daily Active Users (DAU) | 1.4 billion | ~16,000 concurrent users PER SECOND just coming online |
| Messages per day | 100+ billion | ~1.2 million messages PER SECOND sustained |
| Average messages per user per day | ~70 | Inbox storage grows quickly; need efficient storage |
| Media messages (% of total) | ~25% | Massive blob storage requirements (petabytes) |
| Average group size | ~8 members | Fan-out factor for group messages |
| Peak multiplier | ~3x average | Must handle 3.6 million msgs/sec at peaks |
| Geographic distribution | 200+ countries | Latency-sensitive; need global presence |
| Average message size (text) | ~100 bytes | 100 billion × 100 bytes = 10 TB/day of text alone |
| Average media size | ~500 KB | 25 billion × 500 KB = 12.5 PB/day of media |
From these base metrics, we can calculate the system's throughput requirements:
123456789101112131415161718192021222324
MESSAGE THROUGHPUT══════════════════Daily messages: 100 billionSeconds per day: 86,400Average rate: 100B / 86,400 ≈ 1.16 million msgs/secondPeak rate (3x): ~3.5 million msgs/second CONNECTION THROUGHPUT═════════════════════DAU: 1.4 billion usersAverage online time: ~4 hours/day (estimate)Concurrent users: 1.4B × (4/24) ≈ 233 million concurrentAt any second: ~233 million WebSocket connections With graceful degradation, need capacity for:- 300+ million simultaneous WebSocket connections- ~3.5 million message deliveries/second- ~500,000 media uploads/second STORAGE THROUGHPUT══════════════════Text messages: 10 TB/day → ~120 MB/second sustained writeMedia files: 12.5 PB/day → ~150 GB/second sustained writeTotal daily ingest: ~12.5 PB (massive object storage requirement)These calculations reveal why WhatsApp famously ran on just 50 engineers for years—not because the problem is simple, but because they made brilliant architectural choices. Each architectural decision must be evaluated against these numbers. A solution that adds 1ms latency per message means 3,500 extra seconds of server time per second at peak load.
Messaging latency directly impacts user experience. Unlike web page loads where 1-2 seconds is acceptable, chat messages must feel instantaneous. Users subconsciously expect the same responsiveness as in-person conversation.
| Operation | Target P99 Latency | Rationale |
|---|---|---|
| Send message (optimistic UI) | < 50ms | Message should appear 'sent' immediately locally |
| Message delivery to online recipient | < 300ms | Feels real-time; enables natural conversation flow |
| Message delivery to recently offline user | < 2 seconds | Upon reconnection, catch-up should be fast |
| Group message fan-out (1000 members) | < 1 second | All online members should receive 'simultaneously' |
| Media upload start (to first byte acknowledged) | < 500ms | User knows upload has begun |
| Typing indicator propagation | < 200ms | Must feel real-time or it's useless |
| Read receipt delivery | < 500ms | Should appear before user looks away |
| Contact sync (initial) | < 10 seconds | First-time sync with 1000+ contacts |
| Message history load (page of 20) | < 300ms | Scrolling back should feel smooth |
| Search results | < 500ms | Searching through years of messages |
With users in 200+ countries, network Round-Trip Time (RTT) varies dramatically:
Architectural implication: To achieve <300ms message delivery globally, the system cannot depend on more than 1-2 round trips. This rules out architectures requiring:
Edge presence is mandatory. Users must connect to nearby data centers, and message routing must be optimized for geographic proximity when sender and receiver are far apart.
For a 300ms end-to-end delivery target with sender in Brazil and recipient in Japan: ~150ms is just network RTT to the nearest edge server. You have only ~150ms left for all processing: authentication, message queuing, routing, recipient lookup, and push delivery. Every millisecond counts.
Reliability in messaging is non-negotiable. Users will forgive occasional slowness, but they will not forgive lost messages. A messaging system that loses even 0.001% of messages would lose 1 million messages per day at WhatsApp scale—utterly unacceptable.
'Exactly-once delivery' is an impossible guarantee in distributed systems with arbitrary failures. What we actually implement is 'effectively-once' through idempotency:
The realistic guarantee:
This distinction matters architecturally. We must:
The 'Two Generals Problem' proves that reliable delivery over unreliable channels is impossible with finite messages. Our engineering solution is to make this impossibility invisible to users through persistent storage, retries, and idempotent delivery. Understanding this fundamental limitation helps you explain why 100% reliability is theoretically impossible but practically achievable.
Availability measures the percentage of time the system is operational. For a messaging platform that users depend on for daily communication—including emergency situations—availability requirements are exceptionally stringent.
| Availability Level | Downtime/Year | Assessment |
|---|---|---|
| 99% (two nines) | 3.65 days | Unacceptable for messaging |
| 99.9% (three nines) | 8.76 hours | Still too much for critical communication |
| 99.99% (four nines) | 52.6 minutes | Minimum acceptable; typical industry target |
| 99.999% (five nines) | 5.26 minutes | Aspirational target for core messaging |
Achieving 99.99%+ availability requires a carefully designed degradation strategy. Not all features are equally critical:
Tier 1 (Must never fail):
Tier 2 (Brief outages acceptable):
Tier 3 (Can degrade significantly):
During overload or partial failures, the system should shed Tier 3 functionality first, then Tier 2, protecting Tier 1 at all costs. This requires request classification, priority queuing, and circuit breakers at every service boundary.
When network partitions occur, we must choose between Consistency and Availability. For messaging, we typically favor Availability: it's better for users to send messages that might temporarily appear out-of-order than to completely block messaging. We accept eventual consistency for ordering and use conflict resolution strategies rather than blocking writes.
Private messaging carries intimate conversations, financial information, personal photos, and sensitive business communications. Security is not a feature—it's a foundational requirement that shapes every architectural layer.
WhatsApp, Facebook Messenger (secret conversations), Google Messages, and others all use the Signal Protocol (or derivatives) for E2EE. Understanding its key concepts is essential:
Core components:
The protocol's elegance is that it provides:
E2EE creates significant architectural complexity: you cannot index message content server-side, cannot implement server-side search, cannot filter content automatically, and cannot recover messages if users lose their keys. Every feature must be reimagined through the lens of 'the server cannot see message content.'
With exhaustive requirements defined, we must prioritize. In a system design interview, you cannot design everything—and even in production, you cannot build everything at once. Let's establish the Minimum Viable Product (MVP) for a WhatsApp-like system:
For a 45-minute system design interview, focus on:
Explicitly state what you're NOT designing in detail. A clear scope demonstrates senior-level judgment.
In interviews, confidently deferring complex features shows maturity: 'Voice/video calling is a substantial separate system—I'll focus on text messaging today and can discuss calling architecture at a high level if time permits.' Interviewers respect this more than a superficial treatment of everything.
Requirements analysis for a messaging system is far more complex than it first appears. We've established the foundation for all subsequent architectural decisions.
What's next:
With requirements firmly established, we'll explore message delivery guarantees in depth—how to ensure every message reaches its destination exactly once, even across unreliable networks, device failures, and server crashes. We'll examine acknowledgment flows, retry strategies, and the storage patterns that make reliable delivery possible.
You now have a comprehensive framework for analyzing messaging system requirements. This systematic approach—decomposing functional needs, quantifying scale, and establishing non-functional constraints—applies to any system design problem you'll encounter.