WhatsApp Messenger – System Design Interview Preparation

Practice designing a messaging app like WhatsApp. Cover real-time messaging, end-to-end encryption, and group chats.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the WhatsApp design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing WhatsApp is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Delivering to a recipient who may be offline, exactly once, in order, while holding hundreds of millions of persistent connections.

Scale to establish before drawing anything

500M daily users, 40 messages each - about 20B messages a day, 250,000 a second at peak.
Messages are small, around 100 bytes, but the connection count is the hard part: one open socket per online user.
Media is a different system: a reference in the message, bytes in object storage.

Core components

Connection gateway – Holds the WebSocket per device and maps user to the node holding it. Stateful, which makes deployment the hard problem.
Session registry – Which node holds which user. Every message delivery starts with this lookup.
Message queue per recipient – Undelivered messages for offline users, drained on reconnect.
Message store – Sharded by conversation. Retention policy decides whether this is days or forever.
Media service – Pre-signed upload, CDN download. Messages carry a reference, never bytes.

Trade-offs to defend

At-least-once with deduplication – Exactly-once over an unreliable network is a client-side message id plus server-side dedup, not a delivery guarantee. Saying that is the point.
Ordering per conversation, not global – Global ordering costs a sequencer. Per-conversation ordering with a monotonic sequence number is enough and far cheaper.
Group fan-out on write versus read – A 500-member group written out 500 times is simple and expensive; fan-out on read is cheap and makes delivery receipts harder.

Follow-up questions to expect

A user is online on phone and laptop. How does a message reach both, and what happens when one is read?
A gateway node dies holding 200,000 connections. What do those clients experience?
Last-seen and typing indicators at this scale cost more than messages. Would you build them, and how?