How I'd answer “Design WhatsApp” in a mobile interview

Design a messaging app like WhatsApp. You have 45 minutes, a whiteboard, and an interviewer who uses the app every day.

1. Understand the problem

5–10 min

Before drawing anything, pin down what "messaging" means here:

• 1:1 only, or group chats too?
• Do we need sent, delivered and read receipts?
• Can a message be sent while offline?
• Text only, or media and voice notes as well?

For a 45-minute interview I scope to text messages in 1:1 and small group chats, with receipts and offline sends. I name what I'm leaving out: media upload, end-to-end encryption key exchange, and message search. Saying the scope out loud is half the answer.

2. API design

5–10 min

The client needs a paginated history, a way to send, and one live channel.

GET  /conversations/{id}/messages?before={cursor}
POST /messages { clientId, conversationId, body }
WS   /live  -> message, receipt, typing

Every send carries a clientId generated on the device. That is what makes retries safe: the server can drop a duplicate instead of posting the message twice.

3. High-level architecture

10–15 min

The shape is the standard mobile stack: App UI → ViewModel → Repository, with the repository sitting in front of a local DB, a sync queue and a WebSocket. On the server, a gateway routes to the messaging service, which writes to its database.

Writes go to the local DB first; the sync queue sends them when the network is back.

4. Design deep dive

15–20 min

Offline sends

The message is written to the local database immediately and marked pending. A WorkManager job drains the queue with backoff. The UI never waits for the network, which is why the app still feels instant on a train.

Delivery receipts

Receipts are their own message type, not a flag on the original. Each device sends delivered and read events with the id it is acknowledging, and the server fans them out to the other participants.

Reconnects

A socket that drops must not lose messages. On reconnect the client asks for everything after its last known cursor, then re-sends anything still pending.

What interviewers listen for: idempotency via client ids, ordering within a conversation, and never blocking the UI on the network.

5. Wrap-up

0–5 min

With more time I would add end-to-end encryption, resumable media chunks, and push notifications for when the socket is closed. I would monitor delivery latency at p95 and the size of the sync queue on real devices.