Chapter 12: Design a Chat System

volume1 chat websocket real-time messaging

Status: 🟩 Interview ready - Very common question!
Difficulty: Hard
Time to complete: 50 min read + practice

Overview

A chat system enables real-time text communication between individuals and groups. Modern examples include WhatsApp (2B+ users), Facebook Messenger, Slack, and WeChat. This design covers the full spectrum: 1-on-1 messaging, group chats, online presence, and offline delivery.

Why this matters:

Very common interview question at top tech companies
Combines WebSocket, message queues, NoSQL storage, and presence systems
Teaches real-time bidirectional communication at scale
Hard difficulty due to many moving parts (ordering, delivery, presence)

Problem Statement

Design a chat system that:

Supports real-time 1-on-1 and group messaging
Delivers messages to offline users when they come back online
Shows online/offline presence indicators
Works on both mobile and web (multi-device)
Sends push notifications when user is offline
Stores chat history persistently

Step 1: Requirements & Scope (5 min)

Functional Requirements

Clarifying questions:

1-on-1 only or also group chat? → Both, max 100 members per group
Scale? → 50M DAU
Mobile or web? → Both (iOS, Android, browser)
Message volume? → Assume avg 40 messages/day per user
Message history? → Persist messages (users can scroll back)
Delivery receipts? → Optional (sent/delivered/read)
Online presence? → Yes, show who is online
Push notifications? → Yes, for offline users
End-to-end encryption? → Out of scope for core design, mention as extension

Scope:

Real-time 1-on-1 and group messaging (up to 100/group)
Online presence indicators
Push notifications for offline users
Multi-device sync (phone + desktop)
Persistent message storage

Non-Functional Requirements

Low latency: Messages delivered in < 100ms (real-time feel)
Consistency: Message ordering must be preserved within a conversation
Availability: 99.99% uptime (users expect chat to always work)
Durability: Messages must not be lost even if server crashes
Scale: 50M DAU, handle ~2B messages/day (40 msg × 50M users)

Capacity Estimation

DAU: 50M
Messages per user per day: ~40
Total messages/day: 50M × 40 = 2B messages/day
Messages per second: 2B / 86400 ≈ 23,000 msg/sec (peak ~2-3x = ~50K/sec)

Storage per message (avg 100 bytes text): 2B × 100 bytes = 200 GB/day
10-year retention: 200 GB × 365 × 10 ≈ 730 TB

WebSocket connections: 50M concurrent (50M open connections)

Step 2: High-Level Design (15 min)

Client-Server Communication Options

The core challenge: How do clients receive messages in real-time?

Option 1: HTTP Polling ❌ (Bad!)

Client → HTTP GET /messages  (every N seconds)
Server → Return new messages (or empty response)
Client → HTTP GET /messages  (N seconds later)
...repeat forever

Problems:

Client wastes resources asking when there’s nothing new
High server load (millions of empty responses)
Not truly real-time (delay = polling interval)
Wastes bandwidth (headers on every request)

Option 2: Long Polling 🟡 (Better, but still flawed)

Client → HTTP GET /messages  (opens connection, waits)
Server → (holds connection open until new message arrives)
Server → Returns message to client
Client → Immediately opens new long-poll connection
...repeat

Better because: Server only responds when there’s data.

Still has problems:

Server can’t push (client must re-open connection after each response)
Each message requires a new HTTP connection (overhead)
Hard to tell if client is still connected
Doesn’t work well with multiple servers (message on server 1, client on server 2)

Option 3: WebSocket ✅✅ (Best for Chat!)

Client ──── HTTP Upgrade (handshake) ────→ Server
Client ←──────── Persistent Bidirectional ────── Server
Client ←── Server pushes message instantly ────  Server

Why WebSocket wins:

Bidirectional: Both client and server can send messages
Persistent connection: No reconnect overhead
Low latency: No HTTP headers on every message
Real push: Server pushes to client (not client polling)
Industry standard: Used by WhatsApp, Slack, Discord

WebSocket vs HTTP:

Aspect	HTTP	WebSocket
Direction	Client → Server only	Bidirectional
Connection	New connection per request	Persistent (long-lived)
Overhead	Full HTTP headers each time	Minimal after handshake
Server push	Not possible (polling only)	Native support
Use case	Login, REST APIs, file upload	Real-time chat, gaming, feeds

Design decision: Use WebSocket for messaging, HTTP for everything else (login, signup, media upload, profile updates).

Stateless (HTTP/REST):           Stateful (WebSocket):
- Login / signup                 - Send/receive messages
- User profile                   - Online presence
- Group management               - Typing indicators
- Media upload (CDN)             - Message delivery receipts
- Push notification config

Three Core Service Types

┌────────────────────────────────────────────────────────────────┐
│                         Clients                                │
│         (iOS / Android / Browser)                              │
└────────────┬───────────────────────────────────────────────────┘
             │  WebSocket (persistent, for messages)
             │  HTTP (stateless, for everything else)
             ▼
┌────────────────────────────────────────────────────────────────┐
│                       Load Balancer                            │
└────────┬─────────────────────┬──────────────────┬─────────────┘
         ▼                     ▼                  ▼
┌─────────────────┐  ┌──────────────────┐  ┌──────────────────┐
│  Chat Servers   │  │ Presence Servers │  │   API Servers    │
│  (WebSocket)    │  │  (heartbeat,     │  │  (HTTP/REST)     │
│  - Send/receive │  │   online status) │  │  - Login/signup  │
│  - Message sync │  │                  │  │  - Group mgmt    │
│  - Route msgs   │  │                  │  │  - User profile  │
└─────────┬───────┘  └────────┬─────────┘  └──────────────────┘
          │                   │
          ▼                   ▼
┌─────────────────────────────────────────┐
│            Message Queue                │
│         (Kafka / RabbitMQ)              │
│    - Decouple sender from receiver      │
│    - Buffer messages for offline users  │
└─────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────┐
│           Data Storage Layer            │
│  - Key-value store: chat history        │
│    (HBase / Cassandra / DynamoDB)       │
│  - Relational DB: users, groups         │
│    (MySQL / PostgreSQL)                 │
│  - Cache: recent messages, sessions     │
│    (Redis)                              │
└─────────────────────────────────────────┘

Storage Choices

Why two different storage systems?

Relational DB (MySQL/PostgreSQL) for:

User profiles (user_id, name, phone, email)
Friend/contact lists (user_id, friend_id)
Group metadata (group_id, name, members, admin)
These are structured, low-volume, need joins and ACID

Key-Value Store (HBase/Cassandra) for:

Chat message history
Why NOT relational DB for messages?
- Indexes degrade as table grows to billions of rows
- Read/write patterns are append-heavy (not update-heavy)
- Need to scale horizontally across many nodes
- Random access by (conversation_id, time range) → perfect for KV
HBase supports: fast writes, ordered range scans (by time), horizontal scaling
Cassandra: same benefits, better read performance, used by Discord

Redis Cache for:

Active WebSocket sessions (user_id → server_id mapping)
Recent messages (reduce DB load for latest N messages)
Online presence state

Message queue (Kafka) for:

Decoupling chat servers from message delivery
Buffering messages for offline users
Fan-out to multiple recipients (group chat)
Each user has a dedicated inbox queue (or queue partition)

Step 3: Deep Dive (20 min)

Service Discovery with Zookeeper

Problem: With many chat servers, how do we route each user to the best server?

User connects → which chat server should handle them?

Solution: Zookeeper (or etcd) as service discovery + assignment:

User A logs in
    │
    ▼
┌──────────────────────────┐
│  Zookeeper / Service     │
│  Registry                │
│  - Chat Server 1: 12K    │
│    connections           │
│  - Chat Server 2: 9K     │
│    connections           │
│  - Chat Server 3: 6K     │  ← Least loaded
│    connections           │
└───────────────┬──────────┘
                │ Assigns Chat Server 3 to User A
                ▼
        User A → Chat Server 3 (WebSocket)

Zookeeper responsibilities:

Track all chat servers and their load
Assign best server to each user on login
Update assignment if server goes down (reconnect to new server)
Store mapping: user_id → chat_server_id (in Redis too for fast lookup)

Message Flow: 1-on-1 Chat (Detailed)

User A sends "Hello" to User B:

1. User A → Chat Server 1 (WebSocket message)
2. Chat Server 1 → Gets message_id (from ID generator)
3. Chat Server 1 → Stores message in Key-Value store (HBase)
4. Chat Server 1 → Sends ACK back to User A (message received)

5a. Is User B ONLINE?
    → Chat Server 1 → Find User B's chat server (via Redis: user_b → Chat Server 2)
    → Chat Server 1 → Sends to Chat Server 2 via message queue
    → Chat Server 2 → Pushes message to User B via WebSocket

5b. Is User B OFFLINE?
    → Chat Server 1 → Routes to User B's inbox queue (Kafka)
    → Push Notification Service → Sends push notification to User B's device
    → When User B comes online → Pulls pending messages from queue / DB

Detailed flow diagram:

┌──────┐         ┌─────────┐      ┌──────────┐    ┌──────────┐      ┌──────┐
│UserA │         │Chat Srv1│      │  Redis   │    │Chat Srv2 │      │UserB │
└──┬───┘         └────┬────┘      └────┬─────┘    └────┬─────┘      └──┬───┘
   │  "Hello" (WS)    │               │                │              │
   │──────────────────►               │                │              │
   │                  │ get_msg_id    │                │              │
   │                  │──────────────►│                │              │
   │                  │  msg_id=42    │                │              │
   │                  │◄──────────────│                │              │
   │                  │ store(42,msg) │                │              │
   │                  │──────────────►│  (HBase)       │              │
   │   ACK (msg_id=42)│               │                │              │
   │◄──────────────────               │                │              │
   │                  │ lookup(UserB) │                │              │
   │                  │──────────────►│                │              │
   │                  │  Chat Srv 2   │                │              │
   │                  │◄──────────────│                │              │
   │                  │  route(msg)   │                │              │
   │                  │───────────────────────────────►│              │
   │                  │               │                │ push(msg) WS │
   │                  │               │                │─────────────►│

Message ID Design

Critical requirement: Messages within a conversation must be orderable.

Option 1: Global unique ID (Snowflake):

64-bit ID: timestamp + datacenter + worker + sequence
✅ Globally unique
✅ Sortable by creation time globally
❌ Overkill for per-conversation ordering

Option 2: Local sequence number per conversation (Recommended!):

Each conversation has its own auto-incrementing counter
message_id = sequence number within that conversation
Implementation: Redis INCR conversation:{id}:seq

# Generate message ID for a conversation
def generate_message_id(conversation_id):
    seq_key = f"conversation:{conversation_id}:seq"
    return redis.incr(seq_key)  # Atomic increment
 
# Message structure:
{
  "message_id": 42,       # Sequence within conversation
  "global_id": "uuid",    # UUID for dedup (optional)
  "conversation_id": 101,
  "sender_id": 1,
  "content": "Hello!",
  "timestamp": 1640000000000,  # For display, not ordering
  "type": "text"
}

Why local sequence number:

Easier to display in order (just sort by message_id)
Less contention than global ID generator
Natural conversation threading

Why NOT use timestamp alone:

Two messages can have the same millisecond timestamp
Clock skew across servers can cause out-of-order IDs
Always use a sequence number for definitive ordering

Group Chat Architecture

Small groups (≤ 100 members, our spec):

The fanout on write (push) model works well at this scale:

User A sends to Group (100 members):

Chat Server → Message Queue
               ├── User B's inbox queue
               ├── User C's inbox queue
               ├── User D's inbox queue
               └── ... × 100 members

Each online member gets message via their chat server.
Each offline member gets push notification.

# Group message fanout
def handle_group_message(sender_id, group_id, message):
    # Get all group members
    members = db.get_group_members(group_id)
 
    # Store message once
    msg_id = store_message(group_id, sender_id, message)
 
    # Fanout to each member
    for member_id in members:
        if member_id == sender_id:
            continue
        inbox_queue = f"inbox:{member_id}"
        kafka.publish(inbox_queue, msg_id)

Large groups (> 100 members, e.g., Discord) — different strategy:

Fanout on read (pull model) — don’t push to everyone
Store message once, each client fetches on demand
Trade-off: Higher read latency, simpler write path
Our design only requires ≤ 100, so fanout on write is fine

Small vs Large Group Chat:

Aspect	Small Group (≤100)	Large Group (>100)
Strategy	Fanout on write (push)	Fanout on read (pull)
Write path	Send to each member’s queue	Write once to channel
Read path	Real-time push via WS	Client polls/subscribes
Offline delivery	Push notification per user	Client fetches on reconnect
Example	WhatsApp groups	Discord, Slack channels

Online Presence System

How to track who is online?

Naive approach: User sends “I’m online” on connect, “I’m offline” on disconnect.

Problem: Connection drops (network flicker, app background) would cause false “offline” status, frustrating users.

Solution: Heartbeat mechanism

Client → PresenceServer: heartbeat { user_id: 123 }  (every 5 seconds)

PresenceServer logic:
- On heartbeat: update Redis → user:123:lastSeen = now()
- Status = ONLINE if lastSeen < 30 seconds ago
- Status = OFFLINE if lastSeen ≥ 30 seconds ago

No heartbeat for 30 seconds → mark user as offline

Timeline:
t=0   User A connects
t=5   Heartbeat → ONLINE
t=10  Heartbeat → ONLINE
t=15  Heartbeat → ONLINE
t=20  App backgrounded (no heartbeat)
t=35  No heartbeat for 30s... → mark OFFLINE
t=40  User re-opens app → Heartbeat → ONLINE again

Presence propagation:

User B's status changes (OFFLINE → ONLINE):
1. Presence Server detects change
2. Publish status change event to Kafka topic: "presence-updates"
3. All of User B's friends subscribe to presence-updates for User B
4. Their clients get notified via their chat server connection

For efficiency (fan-out problem with many friends):
- Only propagate to online friends (no point notifying offline users)
- Rate limit status updates (don't broadcast every flicker)
- Use pub/sub: User B's friends subscribe to user_b_presence channel

Redis data model for presence:

Key: presence:{user_id}
Value: { "status": "online", "last_heartbeat": 1640000000, "active_devices": ["phone", "web"] }
TTL: 35 seconds (auto-expire if no heartbeat)

Cross-Device Synchronization

Problem: User has phone AND laptop. Message received on phone — laptop must also show it.

Solution: Each device has its own message sync queue / cursor.

User A has 2 devices: Phone and Laptop

Message arrives in User A's inbox:

         ┌─────────────────────────────┐
         │    User A's Inbox           │
         │    Message 1, 2, 3, 4, 5   │
         └───────┬──────────────┬──────┘
                 │              │
         ┌───────▼────┐  ┌──────▼──────┐
         │  Phone     │  │   Laptop    │
         │  cursor: 3 │  │  cursor: 5  │
         │  (offline, │  │  (online,   │
         │  needs 4,5)│  │  up-to-date)│
         └────────────┘  └─────────────┘

Implementation:

Each device stores its own last_synced_message_id
On reconnect, device sends: “Give me all messages after message_id=3”
Server returns messages 4, 5 to phone
This is cursor-based pagination of the message log

Message sync API:

GET /messages/sync?conversation_id=101&after_message_id=3&limit=50

Response:
{
  "messages": [
    { "id": 4, "content": "Hi!", "sender": "UserB", ... },
    { "id": 5, "content": "How are you?", "sender": "UserB", ... }
  ],
  "has_more": false
}

Push Notifications for Offline Users

User B is OFFLINE (app closed):

1. Message arrives in User B's inbox queue
2. Chat Server detects User B is offline (no active WebSocket)
3. Message forwarded to Push Notification Provider
4. Push provider sends push notification to User B's device

┌────────────────┐      ┌──────────────────────────┐
│  Chat Server   │      │  Push Notification       │
│                │─────►│  Service                 │
│ "User B is     │      │                          │
│  offline, send │      │  ┌──────────────────┐    │
│  push"         │      │  │  APNs (iOS)      │──► │ User B's iPhone
│                │      │  │  FCM (Android)   │──► │ User B's Android
│                │      │  │  Web Push        │──► │ User B's Browser
│                │      │  └──────────────────┘    │
└────────────────┘      └──────────────────────────┘

Push notification content:

Don’t include full message text (privacy, payload limits)
Include: sender name, preview (“You have a new message”), conversation_id
On tap: open app → fetch full messages from server

Delivery guarantee:

Message stored in DB before push notification sent
Even if push notification is lost, user sees message when they open app
Message queue ensures at-least-once delivery

Media Messages (Images, Videos)

Problem: Binary files too large for chat servers. Don’t send via WebSocket.

Solution: Separate media upload flow via CDN:

Sending an image:

1. Client uploads image → Object Storage (S3) via API Server
2. Object Storage generates CDN URL
3. Client sends chat message with CDN URL (not the image itself)
4. Receiving client downloads image from CDN URL

[Sender] ──► [S3/Object Storage] ──► CDN
                                      │
[Sender] ──► [Chat Server] ──────────►│
             "image_url": "cdn.../img" │
                                       ▼
                               [Receiver opens URL]

Optimization:

Compress images before upload (client-side)
Generate thumbnails server-side (store separate low-res version)
Lazy load images (only fetch when scrolled into view)

End-to-End Encryption (E2E)

Concept (mention in interview, don’t over-engineer):

WhatsApp uses Signal Protocol for E2E encryption:

1. Each user has a public/private key pair
2. Public keys stored on server, private keys NEVER leave device
3. Message encrypted with recipient's public key on sender's device
4. Server sees only encrypted bytes (can't read content)
5. Decrypted only on recipient's device using private key

Architecture impact:
- Server can't index message content (no search)
- Server stores encrypted blob, not plaintext
- Key exchange happens via server, but keys themselves are safe

Design Summary

Complete Architecture

┌──────────────────────────────────────────────────────────────────┐
│                    CLIENTS (iOS / Android / Web)                 │
│           WebSocket (messages) + HTTP (everything else)          │
└──────┬───────────────────────────────────────────────────────────┘
       │
       ▼
┌──────────────────────┐
│    Load Balancer     │
│  (L4 for WebSocket,  │
│   L7 for HTTP)       │
└──┬───────────────────┘
   │
   ├──────────────────────────────────────────────────────────────┐
   │                                                              │
   ▼                                                              ▼
┌──────────────────────────────────┐            ┌────────────────────────────┐
│         CHAT SERVERS             │            │        API SERVERS         │
│  (Stateful, WebSocket)           │            │  (Stateless, HTTP)         │
│  - Maintain WS connections       │            │  - Login / auth            │
│  - Route messages to recipients  │            │  - User management         │
│  - Handle group fanout           │            │  - Group management        │
│  - Detect online/offline         │            │  - Media upload            │
└────────────┬─────────────────────┘            └────────────────────────────┘
             │
             ▼
┌───────────────────────────────────────────────┐
│             MESSAGE QUEUE (Kafka)             │
│  - Topic per user inbox                       │
│  - Buffer for offline users                   │
│  - Decouple senders from receivers            │
│  - Fan-out for group messages                 │
└──────────────────────┬────────────────────────┘
                       │
         ┌─────────────┼─────────────────┐
         ▼             ▼                 ▼
┌─────────────┐  ┌──────────┐  ┌─────────────────────┐
│  HBase /    │  │  Redis   │  │  Push Notification  │
│ Cassandra   │  │  Cache   │  │  Service            │
│             │  │          │  │  (APNs / FCM)       │
│ - Messages  │  │ - Active │  │                     │
│ - Chat log  │  │   WS     │  │  For offline users  │
│ - 10yr ret. │  │   sessions│ │                     │
│             │  │ - Presence│ │                     │
│             │  │ - Seq IDs │ │                     │
└─────────────┘  └──────────┘  └─────────────────────┘
         ▲
         │
┌─────────────────────┐
│  PRESENCE SERVERS   │
│  - Heartbeat (5s)   │
│  - Online status    │
│  - Status fanout    │
│  - Redis TTL for    │
│    auto-offline     │
└─────────────────────┘
         ▲
         │
┌─────────────────────┐
│  SERVICE DISCOVERY  │
│  (Zookeeper)        │
│  - Assign chat srv  │
│  - Track server load│
│  - Failover routing │
└─────────────────────┘

Key Design Decisions Summary

Decision	Choice	Reasoning
Client-server protocol	WebSocket (messages) + HTTP (REST)	Bidirectional push; HTTP stateless for non-real-time
Message queue	Kafka	Decouple sender/receiver, buffer offline msgs, fan-out
Chat history storage	HBase / Cassandra	Write-heavy, horizontal scale, ordered scan by time
User/group data	MySQL / PostgreSQL	Structured, needs joins, low volume
Cache	Redis	Sessions, presence, sequence IDs — all in-memory
Message ID	Local sequence per conversation	Simple ordering, less contention than global ID
Group fanout	Push to each member’s queue	Works well for ≤ 100 members
Online presence	Heartbeat every 5s, 30s timeout	Handles flaky networks gracefully
Service discovery	Zookeeper	Dynamic server assignment and load balancing
Offline delivery	Push notifications (APNs/FCM)	Native mobile delivery when app is closed

Interview Questions & Answers

Q: Why WebSocket over HTTP long-polling for a chat system?
A: WebSocket provides persistent bidirectional communication — the server can push messages to the client without waiting for a client request. Long polling still requires the client to re-open a connection after every message, adding latency and overhead. For a chat system with frequent messages, the constant reconnect cost of long polling is unacceptable. WebSocket also allows the server to push typing indicators and presence updates at no extra cost.

Q: How do you ensure message ordering in a group chat?
A: Each conversation (1-on-1 or group) maintains a local sequence number using a Redis atomic INCR. Every message sent to that conversation gets the next sequence number. Clients display messages sorted by sequence number, not timestamp, since clock skew across servers can produce misleading timestamps. The sequence number is the single source of truth for message order within a conversation.

Q: How does the system handle a user who is offline for a week?
A: Messages are stored in two places: the persistent key-value store (HBase/Cassandra) and the user’s Kafka inbox queue. When the user reconnects: (1) they request messages after their last-seen message_id, (2) the server returns all newer messages via the sync API, (3) the Kafka consumer group drains the inbox queue and delivers pending messages. The KV store is the source of truth; Kafka is the real-time delivery mechanism.

Q: How do you scale to 50M concurrent WebSocket connections?
A: WebSocket connections are stateful and memory-intensive (~50KB per connection). At 50M connections, that’s ~2.5TB RAM total. We scale horizontally: add more chat servers, each handling ~50K-100K connections. Zookeeper tracks server load and routes new users to least-loaded servers. Redis stores the user_id → chat_server_id mapping so any server can route messages correctly. When a server fails, clients reconnect and Zookeeper assigns a new server.

Q: How do you handle the fanout problem when a user is in 1000 groups?
A: For groups up to 100 members (our spec), fanout on write is acceptable — at most 100 queue writes per message. If we needed to support larger groups (Discord-style channels with thousands of members), we would switch to fanout on read: store the message once and have clients subscribe to the channel and pull messages. The trade-off is increased read latency vs. avoiding massive write amplification on sends.

Q: How do you guarantee message delivery (exactly-once vs at-least-once)?
A: We implement at-least-once delivery with deduplication for exactly-once behavior: (1) Sender gets an ACK from the chat server after the message is stored in DB — if no ACK, the client retries with the same client-side generated UUID. (2) The server deduplicates by checking if the UUID already exists before storing. (3) Kafka ensures at-least-once delivery to the inbox queue. (4) The client tracks the last seen message_id and ignores duplicates. This gives effectively exactly-once visible delivery.

Key Takeaways

WebSocket is the right choice for real-time bidirectional messaging — never use polling for chat
HTTP stays stateless (login, group management, media), only messaging goes over WebSocket
Key-value stores (HBase/Cassandra) are ideal for chat history — write-heavy, append-only, horizontally scalable
Kafka message queues decouple senders from receivers and buffer messages for offline users
Heartbeat mechanism (every 5s, 30s timeout) is more reliable than connect/disconnect events for presence
Local sequence numbers per conversation solve message ordering — don’t rely on timestamps alone
Cross-device sync via cursor (last_seen_message_id) — each device independently tracks its position
Service discovery (Zookeeper) assigns users to chat servers dynamically, enabling horizontal scaling

ch04-rate-limiter - Rate limiting WebSocket connections and API endpoints
distributed-system-components > Message Queue - Kafka for async message delivery
distributed-system-components > Key-Value Store - HBase/Cassandra for chat history
ch05-consistent-hashing - Distributing users across chat servers
ch06-key-value-store - Storage layer design
key-patterns > Real-time Communication - WebSocket patterns

Practice this design! One of the hardest SDI questions. Be ready to:

Justify WebSocket over long polling clearly
Draw the complete architecture with all components
Explain message ordering with local sequence numbers
Walk through both online AND offline message delivery flows
Discuss group chat fanout and scaling limits

Last Updated: 2026-04-13
Status: Very common interview question - Must know!

Study Notes by Niladri & AI

Explorer

ch12-chat-system

Chapter 12: Design a Chat System

Overview

Problem Statement

Step 1: Requirements & Scope (5 min)

Functional Requirements

Non-Functional Requirements

Capacity Estimation

Step 2: High-Level Design (15 min)

Client-Server Communication Options

Option 1: HTTP Polling ❌ (Bad!)

Option 2: Long Polling 🟡 (Better, but still flawed)

Option 3: WebSocket ✅✅ (Best for Chat!)

Three Core Service Types

Storage Choices

Step 3: Deep Dive (20 min)

Service Discovery with Zookeeper

Message Flow: 1-on-1 Chat (Detailed)

Message ID Design

Group Chat Architecture

Online Presence System

Cross-Device Synchronization

Push Notifications for Offline Users

Media Messages (Images, Videos)

End-to-End Encryption (E2E)

Design Summary

Complete Architecture

Key Design Decisions Summary

Interview Questions & Answers

Key Takeaways

Graph View

Table of Contents

Backlinks

Study Notes by Niladri & AI

Explorer

ch12-chat-system

Chapter 12: Design a Chat System

Overview

Problem Statement

Step 1: Requirements & Scope (5 min)

Functional Requirements

Non-Functional Requirements

Capacity Estimation

Step 2: High-Level Design (15 min)

Client-Server Communication Options

Option 1: HTTP Polling ❌ (Bad!)

Option 2: Long Polling 🟡 (Better, but still flawed)

Option 3: WebSocket ✅✅ (Best for Chat!)

Three Core Service Types

Storage Choices

Step 3: Deep Dive (20 min)

Service Discovery with Zookeeper

Message Flow: 1-on-1 Chat (Detailed)

Message ID Design

Group Chat Architecture

Online Presence System

Cross-Device Synchronization

Push Notifications for Offline Users

Media Messages (Images, Videos)

End-to-End Encryption (E2E)

Design Summary

Complete Architecture

Key Design Decisions Summary

Interview Questions & Answers

Key Takeaways

Related Resources

Graph View

Table of Contents

Backlinks