WhatsApp is a distributed real-time messaging system that enables users to communicate instantly by exchanging text messages, media files, voice notes, and other content over the internet. It supports one-to-one and group messaging while ensuring low latency, high scalability, fault tolerance, high availability, and secure end-to-end encrypted communication across billions of users.

Before diving into the system design, it's essential to clarify the requirements with the interviewer. Asking thoughtful questions helps uncover hidden assumptions, remove ambiguities, and establish the scope of the system. This ensures that both the candidate and the interviewer share the same understanding before discussing the architecture.

A typical conversation might look like the following:

 Candidate: What scale should we design for? How many users and messages should the system handle?Interviewer: Assume the system has 500 million Daily Active Users (DAU), with each user sending an average of 40 messages per day.
Candidate: Should the system support only one-to-one messaging, or should it also support group chats?Interviewer: Support both. Group chats should allow up to 500 participants.
Candidate: What types of messages should be supported? Should we consider only text messages or also media such as images, videos, and documents?Interviewer: Focus primarily on text messaging for the core design. You may briefly discuss media handling at a high level, but its detailed implementation is out of scope.
Candidate: Should the system display user presence information such as online/offline status, last seen, and typing indicators?Interviewer: Yes. Presence information, including online/offline status and last seen, is required. Typing indicators are desirable but not critical.
Candidate: What message delivery guarantees are expected? Should users receive delivery and read receipts?Interviewer: Yes. The system should provide sent, delivered, and read receipts. Messages must be delivered reliably and should not be lost.
Candidate: How long should messages be retained? Do we need to support message history across multiple devices?Interviewer: Messages should remain available until explicitly deleted by the user. The system should also support message history synchronization across all of a user's devices.
Candidate: Should end-to-end encryption be part of the design?Interviewer: Yes. Mention end-to-end encryption (E2EE) as a key requirement, but you do not need to explain the underlying cryptographic algorithms in detail.

Based on the discussion, the system should satisfy the following requirements:

Functional Requirements

1. One-to-One Messaging

Users should be able to exchange text messages with other users in real time. Messages should be delivered instantly when both users are online.

2. Group Messaging

Users should be able to create group chats and exchange messages with multiple participants. Each group should support up to 500 members.

3. Message Delivery Status

The system should provide message acknowledgments so users can track the state of each message:

• Sent – The message has been accepted by the server.
• Delivered – The message has reached the recipient's device.
• Read – The recipient has opened and read the message.

4. Presence Information

Users should be able to view the availability of their contacts, including:

• Online
• Offline
• Last Seen

Typing indicators are considered an optional enhancement.

5. Message History & Multi-Device Sync

Messages should be stored persistently until deleted by the user. Users should be able to access and synchronize their conversation history across multiple devices.

6. Push Notifications

If a recipient is offline, the system should send push notifications to alert them of new messages.

Non-Functional Requirements

1. Low Latency

The system should deliver messages with minimal delay to provide a real-time messaging experience.

Target: p99 message delivery latency < 100 ms for online recipients.

2. High Availability

The messaging service should remain operational even during server failures or maintenance.

Target: 99.99% availability (four nines).

3. Reliability & Durability

Messages must never be lost. Once a message is accepted by the server, it should be durably stored and eventually delivered to the recipient, even if the recipient is temporarily offline.

4. Scalability

The architecture should scale horizontally to support massive traffic.

Target Scale:

• 500+ million Daily Active Users (DAU)
• 20+ billion messages per day

5. Message Ordering

Messages within the same conversation should always be displayed in the order they were sent, even if they arrive out of order due to network delays or retries.

6. Consistency

Different parts of the system have different consistency requirements:

• Presence Information: Eventually consistent. Minor delays in online/offline status are acceptable.
• Messaging: Messages should be delivered using at-least-once delivery semantics, while ensuring no duplicate messages are visible to users through idempotency or deduplication.
• Conversation Ordering: Messages within a conversation must maintain a consistent order.

Out of Scope

To keep the discussion focused and manageable within a typical High-Level Design (HLD) interview, we will exclude the following features. While these are important components of a production-grade messaging platform, designing them in detail would significantly expand the scope of the interview.

• Media Messaging: Support for images, videos, documents, GIFs, and voice notes. We may briefly discuss media storage and delivery at a high level, but the detailed design is out of scope.
• Voice and Video Calling: Real-time audio and video communication, including signaling, media streaming, and NAT traversal.
• End-to-End Encryption (E2EE): We will acknowledge E2EE as a key security requirement but will not cover the underlying cryptographic protocols, key management, or encryption algorithms.
• Stories/Status Updates: Ephemeral content sharing (similar to WhatsApp Status) and its associated storage, distribution, and expiration mechanisms.
• Message Search: Full-text search across chat history and indexing strategies.
• Message Editing and Deletion: Editing sent messages and deleting messages for oneself or for everyone.
• Backup and Restore: Cloud backup, device migration, and chat restoration.
• Spam Detection and Content Moderation: Abuse prevention, spam filtering, and policy enforcement mechanisms.

Focus: This design will concentrate on the core messaging workflow—real-time one-to-one and group messaging, message delivery, presence, message persistence, and horizontal scalability. These are the areas most commonly evaluated in HLD interviews.