Design a Chat System (WhatsApp / Slack / Messenger)
Chat is the system design interview's stress test. It combines a stateful, always-open connection per user (unlike the stateless request/response of most web systems), a strict per-conversation ordering requirement, a fan-out problem that changes shape between a 2-person DM and a 10,000-member channel, and a durability bar — a message a user believes was "sent" must never silently vanish. A candidate who treats it like a CRUD app (HTTP POST a message, poll for new ones) has not understood why the problem is interesting.
This subject builds a model answer using the same four-step framework as the rest of this track — requirements → estimation → high-level design → deep dives — and closes with the follow-up questions interviewers reach for once the whiteboard fills up. Boundaries with sibling subjects: the mechanics of choosing a load balancing algorithm are in Load Balancing, the general cache-aside/write-through vocabulary is in Caching Strategies, hash-based shard placement is in Consistent Hashing, and the deep mechanics of exactly-once vs at-least-once queues are in Message Queues and Event Streaming — this subject uses those ideas but does not re-derive them.
Step 1 — Requirements
Functional requirements
| # | Requirement | Clarifying question to ask |
|---|---|---|
| F1 | 1:1 messaging | Text only, or media too? (assume text + small attachments) |
| F2 | Group chat | Max group size? (assume up to ~500 for "small," some channels much larger) |
| F3 | Online presence | Exact ("last seen 2 min ago") or coarse (online/offline)? |
| F4 | Delivery & read receipts | Per-message, per-user in a group? |
| F5 | Message history | How far back? Searchable? |
| F6 | Push notifications | For offline / backgrounded users |
| F7 | Multi-device | Same account on phone + laptop + web, all in sync |
Non-functional requirements
- Low latency: message delivery to an online recipient should feel instant — target well under 200 ms end-to-end.
- Ordering: messages within a single conversation must display in a consistent order for all participants, even if network delivery reorders them.
- Durability: once the server acknowledges a message, it must not be lost, even across server crashes.
- Availability over strict consistency: a chat app should stay usable during partial outages; a few seconds of "sent but not yet delivered" is acceptable, silently dropping a message is not.
- Scale: hundreds of millions of daily active users, most connected continuously for hours.
State the priority: "Ordering and durability per conversation are non-negotiable; global ordering across conversations is not required; presence can be approximate and eventually consistent."