Chat / Messaging System
hardOpen designVery commonly asked~45 minHLD roundBar raiserSenior / SDE-3MetaGoogleAmazonMicrosoftPhonePeQueues & AsyncStorage & Data ModellingConsistency & Consensus
The question, as asked
“Design a messaging app like WhatsApp. Start with one-to-one chat and we'll go from there.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- One-to-one only, or group chat too? Group changes the fanout and the read-receipt model completely — pin it down before designing anything.
- How big can a group get? 10 members and 100,000 members are different systems; the second is closer to a broadcast feed than a chat.
- Online-only delivery, or full offline support? Offline means you need durable per-recipient queues, not just a socket push.
- Do you need delivery and read receipts? They multiply your write volume by roughly the message count again, and they're often the hidden bulk of the traffic.
- How long is message history kept, and is it searchable? Retention drives your storage bill; search drives an entirely separate index.
- End-to-end encrypted? If yes, the server cannot read, index, or search content — which removes several designs from the table immediately.
- Media — images, video, voice notes? These should never travel through the messaging path; confirm you can treat them as separate uploads.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.