01What happens when I hit send in a subway tunnel?
The message renders instantly with a pending tick and sits in a durable outbox; it sends itself when the network returns — the user never retypes.
Premium preview
Chat App
Design the client-side architecture of a WhatsApp-style mobile messenger — connection handling, message state, offline storage, and encryption all have to survive a flaky mobile network.
00
Practice checkpoints
The requirements are open as a taste. From the numbers onward, the full guide opens in the app.
- 01Clarify scope
- 02Requirements + scale
- 03API + data modelUnlocks in the app
- 04Draw architectureUnlocks in the app
- 05Deep diveUnlocks in the app
- 06Trade-off decisionUnlocks in the app
01
Requirements that shape the design
Do not only state requirements. Ask for them. Each card pairs the design constraint with a clarification question you can say out loud before drawing the architecture.
Functional requirements
02How much works with no connection at all?
Everything except delivery: full history, search, composing, media queuing — the local store is the app; the network is a sync detail.
03Where is a message encrypted, and what do the ticks mean?
Encrypted on the device before anything leaves it (the server routes ciphertext); ticks track truthful state — pending (outbox), sent (server ack), delivered (recipient device ack), read.
04Do photos and videos travel the same path as text?
No: media uploads out of band (background, resumable) and the message carries a reference - a text must never queue behind a photo on a bad connection.
05How do notifications work when the app is dead - with end-to-end encryption (E2E)?
Push carries only a wake signal and message id - never plaintext through APNs/FCM; the woken app fetches ciphertext and decrypts locally.
06Backups vs end-to-end encryption - how does history survive a lost phone?
Encrypted backups under a user-held key: lose the key, lose the history - that trade is stated to the user, not hidden.
Out of scopeServer-side fan-out and inbox design (the messenger fan-out sibling question) · Voice/video calling · Encryption protocol internals (key ratcheting math) — the boundary and key handling are in scope, the math is not
Non-functional requirements
01What is the golden rule for the UI thread?
Never wait for the network: reads come from the local store, writes go to the local store + outbox — the socket is a background courier.
02The app is killed mid-send — what survives?
The outbox is durable (local DB, not memory): on next launch, unsent messages resume sending exactly once.
03A retry races a slow ack — can the recipient get it twice?
No: every message carries a client-generated UUID from birth; the server dedups on it, so retries are free.
04What does the connection cost the battery?
One socket, heartbeats in the tens of seconds, reconnect with exponential backoff + jitter — and on mobile OSes, push notifications wake the app instead of holding sockets forever.
05What can the server read?
Routing metadata only: messages are encrypted per recipient device before leaving; the server is a ciphertext router with no key material.
Keep asking — the interview is a conversation
Real interviews probe far more than a tidy list. These are the scope questions that separate candidates who interrogate the problem from those who recite it.
- Is this client-side scoped (state, storage, connection), or do you want the server too?
- Is E2E encryption assumed, and to what depth — boundary or protocol math?
- Multi-device support, or one phone per account?
- What history depth must work offline?
- Which mobile constraints matter most here — battery, data, or cold-start time?
01
Unlock the full playbook for Chat App
Numbers, architecture diagram, API and data model, deep dives, expected topics, self-check, whiteboard starter, and common mistakes unlock inside the app.
Numbers that force architecture decisions
Locked in the app
Architecture path
Locked in the app
API and data model
Locked in the app
Deep dive directions
Locked in the app
+Series