Design a WhatsApp‑like Chat System: System Design Interview Walkthrough (2026)

When interviewers ask you to design a chat system that feels like WhatsApp, they’re looking for three things: a clear understanding of the problem space, a sensible decomposition into services, and the ability to reason about scalability, consistency, and failure modes. Below is a practical walkthrough you can use as a rehearsal script. Feel free to adapt the wording to match your own experiences and resume.

1. Clarify Requirements

Start by confirming what the interviewee expects. A typical set looks like this:

• Functional
  • One‑to‑one and group messaging.
  • Text messages, emojis, and basic media (images, short videos).
  • Presence (online/offline) and read receipts.
  • End‑to‑end encryption (optional for the core design).
• Non‑functional
  • Low latency (sub‑second for most users).
  • High availability (99.9%+ uptime).
  • Horizontal scalability to support millions of concurrent users.
  • Data durability (messages should survive server crashes).

If the interviewer wants to narrow the scope—say, only text messages or only one‑to‑one chats—note that and adjust the design accordingly.

2. Identify Core Entities

These entities map naturally to tables or document collections and guide the API surface.

3. Sketch the API Surface

A minimal REST‑style (or gRPC) contract might include:

• POST /users/register – create a new account.
• GET /users/:id/presence – fetch current status.
• POST /conversations – start a DM or group.
• GET /conversations/:id/messages?after=msg_id – paginate recent messages.
• POST /messages – send a new message.
• POST /attachments – upload media, return a URL.
• POST /messages/:id/read – record a read receipt.

During the interview you can show the request/response shape in a quick JSON snippet. Keep it concise; the focus is on how the service layers handle the calls.

4. High‑Level Architecture

Below is a text diagram you can draw on the whiteboard. Use simple boxes and arrows; the interviewer will fill in details.

+----------------+      +----------------+      +-------------------+
|   Client App   | ---> | API Gateway    | ---> | Auth Service      |
+----------------+      +----------------+      +-------------------+
                              |                     |
                              v                     v
                      +----------------+   +-------------------+
                      | Message Service|   | Presence Service |
                      +----------------+   +-------------------+
                              |                     |
            +-----------------+---------------------+-----------------+
            |                 |                     |                 |
            v                 v                     v                 v
   +----------------+  +----------------+   +----------------+  +----------------+
   | Write Queue   |  | Read Queue     |   | Storage (SQL) |  | Object Store   |
   +----------------+  +----------------+   +----------------+  +----------------+
            |                 |                     |
            v                 v                     v
   +---------------------------------------------------------------+
   |                 Notification / Push Service                    |
   +---------------------------------------------------------------+

Key components

• API Gateway – throttles, routes, and terminates TLS.
• Auth Service – validates JWTs or short‑lived tokens.
• Message Service – receives a POST /messages, writes to a durable log (e.g., Kafka) and forwards to the write queue.
• Write Queue – ensures ordering per conversation; consumers persist to the primary database and push to the notification service.
• Read Queue – handles fetches, applies caching (Redis) for recent messages.
• Storage – relational DB for metadata, object store for attachments.
• Presence Service – updates a fast key‑value store (Redis) with heartbeat pings.
• Notification Service – sends APNs/FCM pushes using device tokens.

5. Deep Dive: Ordering & Consistency

Problem: Users expect messages to appear in the order they were sent, even under high concurrency.

Solution pattern:

1. Per‑conversation partitioning – assign each conversation a partition key in the log. All producers for that conversation land in the same partition, preserving order.
2. Idempotent writes – attach a client‑generated UUID to each message; the consumer can deduplicate if a retry occurs.
3. Read‑after‑write guarantee – after persisting, the write consumer publishes an event that the read cache invalidates, ensuring the next fetch sees the new message.

Trade‑offs: Using a single log partition per conversation limits parallelism for very active groups, but it simplifies ordering. If you anticipate massive group chats, you can shard by a combination of conversation_id and a monotonic sequence, then re‑order at the client side using timestamps.

6. Deep Dive: Offline Delivery & Push

When a recipient is not connected, the system must store the message and trigger a push.

• Durable log – the write queue writes to the DB before acknowledging the client. The DB row includes a delivered flag.
• Push worker – reads undelivered rows, looks up the latest device token from the user profile, and sends a push. After a successful push, it flips the flag.
• Retry logic – exponential back‑off for transient failures; after a configurable number of attempts, the message is marked as “failed” and appears in a “sent but not delivered” UI.

Why not just rely on the client: Mobile OSes often kill background processes; a server‑side push guarantees delivery even when the app is closed.

7. Scaling the Write Path

A chat app is write‑heavy: each user sends a message, which creates a row and possibly an attachment upload.

• Horizontal scaling – add more partitions to the log; each partition can be processed by its own consumer group.
• Back‑pressure handling – the API gateway can return a 429 if the write queue length exceeds a threshold, prompting the client to retry with jitter.
• Stateless services – keep message service stateless; all state lives in the log and DB, making it easy to spin up more instances.

8. Common Follow‑Up Questions

When the interviewer probes, walk through the impact on each component rather than diving straight into code. Show that you can reason about latency, storage cost, and operational complexity.

9. Trade‑offs Summary

Pick the simpler row when the interview is time‑boxed; mention the alternative to show depth.

How to practice this

1. Rehearse aloud – use Call Assistant to read your answer and keep the flow tight; it will remind you to stay on the core story.
2. Whiteboard the diagram – draw the architecture without notes, then explain each arrow in under a minute.
3. Mock follow‑ups – have a friend ask the four common questions above and answer them without looking at your notes.

---

FAQ

• What is the most important first step in a system design interview? Clarify the functional and non‑functional requirements. It tells the interviewer you’re thinking about scope before diving into details.

• How many services should I include in my design? Keep it to a handful that cover distinct responsibilities (auth, messaging, presence, storage, notification). Adding unnecessary services can confuse the interview.

• Do I need to implement end‑to‑end encryption for a WhatsApp‑like design? Not for the core design unless the prompt explicitly asks. You can mention it as an optional extension and outline the key exchange flow.

• What if I run out of time before covering everything? Summarize the high‑level flow, highlight the hardest part (usually ordering or offline delivery), and note the trade‑offs you would explore later.