Problem Statement

Design WhatsApp: a messaging platform serving 2+ billion users with emphasis on reliability, minimal infrastructure, offline message sync, and guaranteed delivery. The system must work well on low-end devices with poor network connectivity, support E2E encryption, and handle billions of messages daily with remarkably small engineering teams.

Why This Problem Matters

• WhatsApp is famous for extreme efficiency: ~50 engineers supporting 900M users at acquisition. Understanding their architecture reveals powerful simplicity.
• Tests ability to design for unreliable networks and offline-first usage patterns.
• Demonstrates how constraints (small team, global scale) drive architectural decisions.

Thought Process

Step-by-Step Reasoning

1. Connection: Client establishes persistent connection via custom protocol (or WebSocket) → Server tracks connection state in memory → Heartbeat every 30s to detect disconnection.
2. Send Message: Client encrypts message → Sends to server with local message ID → Server stores in Messages DB → Returns ACK with server message ID → Client shows single checkmark (sent).
3. Deliver Message: Server checks if recipient connected → If yes, pushes immediately → Recipient ACKs receipt → Server forwards ACK to sender → Sender shows double checkmark (delivered).
4. Offline Handling: If recipient offline, message stays in server queue → When recipient connects, server pushes all pending messages → Client processes in order and ACKs each.
5. Read Receipt: When recipient opens chat, client sends "read" event for latest message → Server notifies sender → Blue checkmarks shown.
6. Multi-device Sync: Each device has device_id → Messages delivered to all registered devices → Each device ACKs independently → Message deleted from server only when all devices ACK.

Dry Run

Complexity Analysis

Annotated Solution

// WhatsApp-style message delivery pseudocode
public class MessageDeliveryService {
    private MessageStore messageStore;
    private ConnectionManager connectionManager;
    private DeviceRegistry deviceRegistry;

    public SendResult sendMessage(String senderId, String recipientId,
                                   EncryptedMessage message) {
        // 1. Store message (source of truth)
        String messageId = messageStore.store(message);

        // 2. Attempt delivery to all recipient devices
        List<String> devices = deviceRegistry.getDevices(recipientId);

        for (String deviceId : devices) {
            attemptDelivery(messageId, recipientId, deviceId);
        }

        return new SendResult(messageId, MessageStatus.SENT);
    }

    private void attemptDelivery(String messageId, String recipientId,
                                  String deviceId) {
        Connection conn = connectionManager.getConnection(recipientId, deviceId);

        if (conn != null && conn.isActive()) {
            // Online: push immediately
            Message message = messageStore.get(messageId);
            conn.send(message);
            // Wait for ACK asynchronously
        }
        // If offline: message stays in store, delivered on connect
    }

    public void onDeviceConnected(String userId, String deviceId) {
        // Deliver all pending messages for this device
        List<Message> pending = messageStore.getPending(userId, deviceId);
        Connection conn = connectionManager.getConnection(userId, deviceId);

        for (Message message : pending) {
            conn.send(message);
        }
    }

    public void onDeliveryAck(String messageId, String deviceId) {
        // Mark delivered to this device
        messageStore.markDelivered(messageId, deviceId);

        // If delivered to all devices, notify sender
        if (messageStore.isFullyDelivered(messageId)) {
            notifySenderDelivered(messageId);
            // Can now delete from server (optional, for privacy)
        }
    }
}

Common Pitfalls

• Message ordering: Network delays can cause reordering. Use timestamp + sender + sequence for deterministic ordering.
• Duplicate messages: Client retries can cause duplicates. Use idempotency keys (local message ID) for deduplication.
• Offline duration limits: Can't store pending messages forever. Set reasonable TTL (30 days) with user notification.
• Presence accuracy: "Last seen" can be stale. Use eventual consistency—accuracy within minutes is acceptable.

Follow-Up Questions

• How would you implement message backup to cloud? (Encrypt with user key, store in Google Drive/iCloud, restore on new device)
• How do you handle group chats with 1000+ members? (Sender keys for encryption, fan-out through message queues, delivery receipts sampled)
• How would you implement voice/video calls? (WebRTC for media, signaling through existing message channel)

Key Takeaways