Designing a Chat Application Frontend

The plain-language idea

The prompt: "Design the frontend architecture for a chat application" — think Slack- or WhatsApp-style, with one-on-one and group conversations, message history, typing indicators, and delivery/read receipts. Most of the pieces this prompt needs were already covered earlier in this track; the value here is seeing them applied together to one concrete scenario.

See it in a real thing: designing a chat application

Real-time delivery. A chat app is the textbook case where WebSockets are the right call, not the over-engineered one — applying the real-time-choice framework from earlier in this track, a chat app genuinely needs bidirectional, low-latency communication: the client both receives messages and sends them back over the same live channel. That's precisely the requirement that justifies a WebSocket instead of SSE or polling.

Message list rendering. A long-running conversation's history can run into the thousands of messages, which is a strong case for the pagination and infinite-scroll strategies covered earlier in this track: load the most recent page of messages first, then fetch older messages on scroll-up rather than pulling the entire history at once. That keeps the initial load fast and bounds how much the client holds in memory at any time.

Optimistic sending. A message a user sends should appear in the UI instantly, in a "sending…" state, before the server has confirmed it — a direct application of the optimistic-updates lesson earlier in this track, including its failure and rollback handling: if the send fails, the message needs a visible failed state and a retry affordance, not a silent disappearance.

What's genuinely new here: typing indicators and read receipts. These are a separate, lightweight real-time signal, distinct from the actual message-content stream, in the same spirit as the collaborative editor's presence channel from the previous lesson. "So-and-so is typing" and "seen at 10:42" are low-stakes and ephemeral — losing one update costs nothing, since the next one supersedes it within seconds — so they don't need the same durability or ordering guarantees as an actual message. Routing them over a separate, lighter channel (or a separate message type on the same socket that the client treats as disposable) keeps the guarantees for real message delivery from being diluted by a much noisier, lower-stakes stream.

What people usually miss

Watch out

• This prompt is a synthesis, not a new topic — a strong answer explicitly names which earlier decision (real-time choice, pagination, optimistic updates) it's applying and why, rather than re-deriving each from scratch as if seeing it for the first time.
• Typing indicators and read receipts sharing the message socket is fine, but sharing its guarantees is not. Treating "someone is typing" with the same delivery/ordering requirements as an actual message is unnecessary complexity for a signal that's disposable by nature.
• Optimistic sending needs a visible failure path, not just a happy path. A message that silently vanishes on send failure, instead of showing a retry, is a broken UX regardless of how correct the optimistic-append logic is.
• Group conversations complicate "read" in a way one-on-one chat doesn't — read receipts for a group need per-member read state, not a single boolean, which is worth flagging as a scoping question rather than assuming.

Why this matters in interviews

"Design a chat app" is asked specifically because it forces a candidate to combine several separate decisions into one coherent design — interviewers are listening for whether those connections get made explicitly, not just whether each piece individually is correct.