System Design Interview
Mobile messaging platform inspired by WhatsApp: persistent connections, store-and-forward delivery (the server keeps messages only until they're delivered), push for offline phones, server-side group fan-out and Signal-protocol end-to-end encryption with encrypted media. A teaching design, not Meta's internal architecture.
See why polling a server that keeps every message can't serve billions of phones.
What was missing: Nothing yet: phones poll one server that stores every message.
Why that's risky: Polling multiplies requests by every idle phone, messages arrive only on the next poll, and the database grows forever with content the server never needs again.
What gets added: A chat server that phones poll every few seconds, and a database keeping every message forever.
Trade-offs: Simple request/response, but it wastes battery and server capacity on empty polls.
Push messages the moment they are sent, and keep them on the server only until they are delivered.
What was missing: Phones polled for new messages, and the server kept every message forever.
Why that's risky: An offline phone only gets its messages when the user happens to open the app.
What gets added: Chat gateways holding one persistent connection per online phone, a session registry recording which gateway each user is on, a chat service that routes each message to the recipient's gateway or into their offline inbox, and sent/delivered receipts.
Trade-offs: Store-and-forward keeps the server small and private (messages are deleted on delivery), but chat history lives only on phones and their backups.
Wake up offline phones so they connect and fetch their messages.
What was missing: Offline phones had no way of knowing a message was waiting.
Why that's risky: Group messages would make the sender upload one copy per member.
What gets added: A push queue and workers that wake offline recipients through APNs and FCM. The notification carries no readable content; the phone connects and fetches from its inbox.
Trade-offs: Push providers are outside our control and can delay or drop notifications; the inbox, not the push, is what guarantees delivery.
Send once from the phone and deliver to every member of a group.
What was missing: There were only one-to-one chats; a group would mean one upload per member.
Why that's risky: The server can still read every message and every photo passes through it unencrypted.
What gets added: A group service and database for membership, and a fan-out queue and worker: the sender uploads a group message once, and the worker delivers a copy to each member's gateway or offline inbox.
Trade-offs: Fan-out happens on the server, so a 1,024-member group means 1,024 deliveries per message; groups are capped to bound this.
Make the server unable to read messages or media, and move media out of the chat path.
What was missing: Messages and media were readable on the server, and media travelled through the chat path.
Why that's risky: Spammers can still blast messages, and nobody can see delivery latency or backlogs.
What gets added: A key service and store distributing public identity keys and one-time prekeys so phones set up end-to-end encrypted sessions (Signal protocol). Media is encrypted on the phone, uploaded to object storage and served by a CDN; the chat carries only its URL and key.
Trade-offs: The server can't scan content or offer server-side search; it only ever sees ciphertext and metadata needed for routing.
Slow down spam and watch delivery health.
What was missing: No protection against bulk sending, and no view of the system's health.
Why that's risky: Remaining risk is regional: losing a data centre means its phones reconnect elsewhere while the inbox fails over.
What gets added: An abuse limiter capping sends and new-chat rates per account, and monitoring of connection counts, delivery latency, inbox backlog and push failures.
Trade-offs: Rate limits can slow legitimate bursts (New Year's Eve); limits are per account and generous for established ones.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
