· SWE Editorial · System Design · 5 min read
Design a Chat System: System Design Interview Guide
A structured framework for answering the chat system design interview question, covering WebSocket connections, message ordering, group chat, read receipts, and offline delivery.
“Design a chat system” is one of the most consistently asked system design interview questions across FAANG and mid-size companies alike, because it forces you to reason about real-time delivery, consistency, and scale all at once. The candidates who stand out aren’t the ones who mention WebSockets first — they’re the ones who methodically work through message ordering, offline delivery, and group chat fan-out before an interviewer even has to ask. This guide gives you a repeatable framework for answering the question with the depth a senior loop expects.
Core Concepts
| Concept | What it means | Why it matters in interviews |
|---|---|---|
| WebSocket connections | A persistent, bidirectional connection between client and server used for real-time message delivery | Interviewers expect you to know why WebSockets beat polling for this use case, and what happens when a connection drops |
| Message ordering | Ensuring messages appear in a consistent, causally correct sequence for every participant | A frequent follow-up: “what happens if two messages arrive out of order?” |
| Group chat | Delivering a single message to N recipients, each potentially on a different device or connection | Tests your understanding of fan-out strategies and their tradeoffs at scale |
| Read receipts | Tracking and propagating per-message, per-recipient read state | A seemingly small feature that reveals whether you think about write amplification |
| Offline delivery | Ensuring messages sent while a recipient is disconnected are delivered once they reconnect | Distinguishes candidates who design for the happy path from those who design for reality |
Interview Answer Framework
Work through these four steps out loud, in order, regardless of which specific angle the interviewer opens with:
- Clarify scope and scale. Ask about expected concurrent users, whether it’s 1:1 chat, group chat, or both, message retention requirements, and whether media (images/files) is in scope. State your assumptions explicitly (e.g., “I’ll assume 50M daily active users, average group size of 20, and text-only for the first pass”) so the interviewer can redirect you early if you’re off track.
- Design the connection layer. Describe a connection gateway service that holds persistent WebSocket connections, using a lightweight session table (often in Redis) mapping user ID to the specific gateway server holding their connection. Explain how you’d handle connection drops with exponential backoff reconnect and how the client resyncs missed messages using a last-seen message ID or timestamp.
- Design message delivery, ordering, and fan-out. For 1:1 chat, describe routing a message through a broker to the recipient’s connection server. For group chat, describe the fan-out tradeoff explicitly: fan-out-on-write (push to every member’s inbox immediately, fast reads but expensive writes for large groups) versus fan-out-on-read (store once, let each client pull, cheaper writes but slower reads). State which you’d pick for typical group sizes and why. For ordering, describe using a monotonically increasing per-conversation sequence number so clients can detect gaps and request missing messages.
- Handle offline delivery and read receipts. Explain that offline delivery requires persisting messages in a durable store keyed by recipient, with a delivery queue that flushes once the client reconnects and acknowledges receipt. For read receipts, describe batching receipt updates rather than sending one write per message to avoid write amplification in large groups, and mention that receipts are a good candidate for eventual consistency since a few seconds of staleness doesn’t hurt UX.
Common Follow-ups
Expect: “How do you handle a user with multiple active devices?” (answer: fan out to all active connections for that user ID, and use a per-device delivery cursor so read state syncs correctly), “How would you scale the connection layer to millions of concurrent connections?” (answer: horizontally scale stateless gateway servers behind a load balancer, with a shared session registry so any gateway can route to any user), and “What happens if the message broker goes down mid-delivery?” (answer: persist messages to durable storage before acking the sender, so no message is lost even if downstream delivery temporarily fails).
Production Considerations
Real chat systems spend more engineering effort on failure recovery than on the happy path. Connection churn is constant — mobile clients disconnect and reconnect frequently due to network switches, so your reconnect and resync logic needs to be cheap and fast, not a full history replay every time. Group chat fan-out costs scale non-linearly with group size, so most production systems switch strategies above a certain member threshold (fan-out-on-write for small groups, fan-out-on-read or hybrid for very large ones like broadcast channels). Message ordering guarantees also need to be explicit in your API contract — most systems settle for “ordered per conversation” rather than global ordering across all conversations, since that would require a much more expensive coordination layer.
FAQ
Do I need to mention a specific message broker technology like Kafka? It helps to name one (Kafka or a similar log-based broker is common) but the interviewer cares more about whether you understand why you need durable, ordered delivery than which specific product you name.
How deep should I go on WebSocket connection management in a 45-minute interview? Deep enough to show you understand the stateful nature of the problem — that a specific gateway server holds a specific connection, and that routing a message to a user requires knowing which server that is. You don’t need to discuss TCP internals unless asked.
What’s the biggest mistake candidates make on this question? Jumping straight to “use WebSockets” without addressing offline delivery, ordering, or group chat fan-out — those follow-up areas are where the interview signal actually comes from.
The most comprehensive preparation system we have reviewed for this topic is The 0-to-1 SWE Interview Playbook (Amazon: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20).