Design a Chat Application
Problem Statement
Design a chat application from a client product architecture perspective. The interviewer usually sketches three surfaces:
- A conversation list showing each thread's last message, timestamp, and unread count.
- A message thread with a scrollback history, per-message delivery ticks, and a composer.
- A presence and typing affordance, plus read receipts on your own outgoing messages.
You are designing the client and the contract it talks to: the UI, the client data layer, and the API. Message delivery below that contract is a single box. Persist messages with a chat service sharded by conversation id, and assume the socket delivers what it is given.
This walkthrough follows the Product Architecture framework: requirements, data model, API design, high-level client architecture, and product trade-offs.
Treat this as a client architecture interview. Define the API contracts you need, then spend the bulk of your time on the send state machine, the outbox, ordering, pagination, and how the UI represents every failure mode. The interviewer is listening for what the client does while a request is in flight.
The System Design round asks for the same product below the API line, covered in Design WhatsApp. The split is simple: System Design asks how a message reaches a device, Product Architecture asks what the sender's bubble looks like from the moment they tap send until a blue tick appears.
Common Aliases
- Design a messaging app
- Design WhatsApp or Messenger from the client side
- Design a real-time chat client
- Frontend system design: chat with read receipts and presence
Level Calibration
The same answer is scored differently by level. What "complete" means, in sections of this lesson:
| Level | What a complete answer looks like |
|---|---|
| Mid-level | Phase 1 requirements, the Phase 2 data model, the five core endpoints from the Board Budget, and the Phase 4 send state machine. Roughly 80% breadth to 20% depth. All four right is a clean pass. |
| Senior | The above, plus the durable outbox and the ordering-without-clocks story, plus one deep dive taken to the bottom when the interviewer picks it. Roughly 60/40. |
| Staff+ | The above, plus multi-device reconciliation and privacy expressed as API shape rather than UI suppression. Expect two deep dives, not one. Roughly 40/60. |
The depth below is written at senior to staff. A mid-level reader should treat Phase 5 as reference to reach for when probed, not as a script to deliver.