System Design: Chat Real-time quy mô triệu user

Posted on: 4/21/2026 8:15:59 PM

Tại sao thiết kế Chat System là bài toán khó?

Mỗi ngày, WhatsApp xử lý hơn 100 tỷ tin nhắn, Telegram phục vụ 900 triệu người dùng hoạt động. Đằng sau giao diện đơn giản — gõ, gửi, nhận — là một kiến trúc phân tán cực kỳ phức tạp phải giải quyết đồng thời: truyền tin real-time với độ trễ dưới 200ms, đảm bảo tin nhắn không bao giờ mất, scale lên hàng triệu kết nối đồng thời, và hỗ trợ group chat lên đến 200.000 thành viên.

Bài viết này sẽ đi sâu vào kiến trúc của một hệ thống Chat real-time quy mô lớn — từ WebSocket connection management, message routing, database design cho đến presence system và end-to-end encryption — dưới góc nhìn System Design cho production thực tế.

Phân tích yêu cầu hệ thống

Functional Requirements

• 1:1 Chat: Gửi và nhận tin nhắn real-time giữa hai người dùng
• Group Chat: Hỗ trợ nhóm lên đến hàng nghìn thành viên
• Online/Offline Status: Hiển thị trạng thái hoạt động của user
• Read Receipts: Xác nhận tin nhắn đã gửi, đã nhận, đã đọc (sent → delivered → read)
• Push Notification: Thông báo khi user offline
• Media Sharing: Gửi ảnh, video, file đính kèm
• Message History: Lưu trữ và đồng bộ lịch sử tin nhắn đa thiết bị

Non-functional Requirements

• Low Latency: End-to-end delivery dưới 200ms cho 99th percentile
• High Availability: 99.99% uptime (tối đa 52 phút downtime/năm)
• Message Ordering: Tin nhắn phải hiển thị đúng thứ tự trong conversation
• At-least-once Delivery: Không được mất tin nhắn, chấp nhận duplicate (client dedup)
• Scalability: Scale horizontal lên 50M+ concurrent connections

Kiến trúc tổng quan

graph TB
    subgraph Clients["📱 Clients"]
        C1[Mobile App]
        C2[Web App]
        C3[Desktop App]
    end

    subgraph Edge["Edge Layer"]
        LB[Load Balancer
Sticky Sessions]
    end

    subgraph WS["WebSocket Gateway Cluster"]
        WS1[WS Server 1
~500K connections]
        WS2[WS Server 2
~500K connections]
        WS3[WS Server N
~500K connections]
    end

    subgraph Services["Application Services"]
        MS[Message Service]
        PS[Presence Service]
        GS[Group Service]
        NS[Notification Service]
        SYNC[Sync Service]
    end

    subgraph MQ["Message Queue"]
        K[Kafka / RabbitMQ]
    end

    subgraph Storage["Data Layer"]
        DB[(Message DB
Cassandra/ScyllaDB)]
        CACHE[(Session Cache
Redis Cluster)]
        S3[Media Storage
S3/R2]
        IDX[(Search Index
Elasticsearch)]
    end

    C1 & C2 & C3 --> LB
    LB --> WS1 & WS2 & WS3
    WS1 & WS2 & WS3 --> MS
    MS --> K
    K --> DB
    K --> NS
    WS1 & WS2 & WS3 --> PS
    PS --> CACHE
    MS --> GS
    NS --> C1 & C2 & C3
    SYNC --> DB

    style LB fill:#e94560,stroke:#fff,color:#fff
    style K fill:#2c3e50,stroke:#fff,color:#fff
    style DB fill:#16213e,stroke:#fff,color:#fff
    style CACHE fill:#e94560,stroke:#fff,color:#fff

Kiến trúc chia thành 4 tầng chính: Edge Layer xử lý kết nối và phân tải; WebSocket Gateway duy trì kết nối persistent với client; Application Services xử lý business logic; và Data Layer lưu trữ tin nhắn, session, media.

WebSocket Gateway — Trái tim của hệ thống

WebSocket là giao thức nền tảng cho chat real-time vì nó duy trì kết nối hai chiều (bidirectional) liên tục giữa client và server, khác với HTTP request-response truyền thống. Khi user mở app, một WebSocket connection được thiết lập và giữ mở trong suốt phiên sử dụng.

Connection Management

Mỗi WebSocket server có thể quản lý 500K–1M kết nối đồng thời nhờ sử dụng event-driven I/O (epoll trên Linux). Với 50 triệu concurrent connections, cần khoảng 50–100 WebSocket server.

sequenceDiagram
    participant C as Client
    participant LB as Load Balancer
    participant WS as WS Gateway
    participant R as Redis (Session)
    participant MS as Message Service

    C->>LB: WebSocket Handshake
    LB->>WS: Route (Sticky by User ID)
    WS->>R: Register session
{userId: ws-server-3, connId: abc123}
    R-->>WS: OK
    WS-->>C: Connection Established

    Note over C,WS: Heartbeat mỗi 30s để giữ connection

    C->>WS: Send Message {to: user_B, text: "Xin chào"}
    WS->>MS: Route message
    MS->>R: Lookup user_B session
    R-->>MS: {server: ws-server-7, connId: xyz789}
    MS->>WS: Deliver to ws-server-7
    WS->>C: Message delivered ✓

Heartbeat & Reconnection

Client gửi heartbeat (ping/pong) mỗi 30 giây. Nếu server không nhận được heartbeat trong 90 giây, connection được đánh dấu dead và session bị xóa khỏi Redis. Client-side có retry logic với exponential backoff: 1s → 2s → 4s → 8s → tối đa 30s.

Message Routing — Đưa tin nhắn đến đúng người

1:1 Chat Flow

Khi user A gửi tin nhắn cho user B:

1. WS Gateway nhận message từ A, gán messageId (Snowflake ID — đảm bảo unique + sortable theo thời gian) và timestamp
2. Message Service validate, enqueue vào Kafka topic messages
3. Consumer persist vào database (write-ahead), gửi ACK lại cho sender
4. Router tra Redis để tìm WebSocket server của user B
5. Nếu B online: push qua WebSocket → B gửi delivery receipt → update status thành delivered
6. Nếu B offline: message nằm trong inbox, trigger push notification qua FCM/APNs

Group Chat — Bài toán Fan-out

Group chat là thách thức lớn nhất về mặt scale. Khi 1 user gửi tin vào group 10.000 thành viên, hệ thống phải fan-out message đến tất cả — đây gọi là write amplification.

graph LR
    subgraph Write["Fan-out on Write"]
        A1[User gửi msg] --> B1[Message Service]
        B1 --> C1[Copy → Inbox User 1]
        B1 --> D1[Copy → Inbox User 2]
        B1 --> E1[Copy → Inbox User N]
    end

    subgraph Read["Fan-out on Read"]
        A2[User gửi msg] --> B2[Message Service]
        B2 --> C2[Lưu 1 bản
trong Group Store]
        D2[User 1 mở chat] --> C2
        E2[User 2 mở chat] --> C2
    end

    style B1 fill:#e94560,stroke:#fff,color:#fff
    style B2 fill:#e94560,stroke:#fff,color:#fff
    style C2 fill:#2c3e50,stroke:#fff,color:#fff

WhatsApp dùng fan-out on write vì group tối đa 1.024 thành viên — write amplification chấp nhận được. Telegram dùng hybrid: fan-out on write cho group nhỏ, fan-out on read cho supergroup lên đến 200.000 thành viên.

Database Design — Lưu trữ hàng tỷ tin nhắn

Chọn database phù hợp

Chat message có đặc tính: write-heavy (ghi liên tục), recent-read-heavy (đọc chủ yếu tin mới), append-only (không sửa, ít xóa), time-series-like (query theo thời gian). Các đặc tính này phù hợp với wide-column store hơn RDBMS truyền thống.

Schema thiết kế cho Cassandra

-- Bảng message: partition by conversation, cluster by time
CREATE TABLE messages (
    conversation_id UUID,
    message_id BIGINT,       -- Snowflake ID (time-sortable)
    sender_id UUID,
    message_type TEXT,        -- 'text', 'image', 'video', 'file'
    content TEXT,
    media_url TEXT,
    status TEXT,              -- 'sent', 'delivered', 'read'
    created_at TIMESTAMP,
    PRIMARY KEY (conversation_id, message_id)
) WITH CLUSTERING ORDER BY (message_id DESC);

-- Bảng conversation inbox: mỗi user có list conversations
CREATE TABLE user_conversations (
    user_id UUID,
    last_message_at TIMESTAMP,
    conversation_id UUID,
    conversation_type TEXT,   -- '1:1' hoặc 'group'
    last_message_preview TEXT,
    unread_count INT,
    PRIMARY KEY (user_id, last_message_at, conversation_id)
) WITH CLUSTERING ORDER BY (last_message_at DESC);

Hot/Cold Storage Tiering

Không phải tất cả tin nhắn đều được truy cập thường xuyên. Chiến lược phân tầng:

• Hot (0-7 ngày): Redis sorted set — truy vấn cực nhanh, lưu 50 tin gần nhất mỗi conversation
• Warm (7-90 ngày): Cassandra/ScyllaDB — storage chính, SSD-backed
• Cold (90+ ngày): Object storage (S3) dạng compressed Parquet — chi phí cực thấp, query khi cần qua Spark/Presto

Presence System — "Online", "Last seen", "Typing..."

Presence system theo dõi trạng thái real-time của user: online, offline, last seen, typing. Đây là tính năng tưởng đơn giản nhưng scale rất khó vì mỗi thay đổi trạng thái phải broadcast cho tất cả contact của user đó.

stateDiagram-v2
    [*] --> Online: WebSocket connected
    Online --> Away: Không hoạt động > 5 phút
    Away --> Online: User tương tác
    Online --> Offline: Disconnect / Heartbeat timeout
    Away --> Offline: Heartbeat timeout
    Offline --> Online: Reconnect

    Online --> Typing: Bắt đầu gõ
    Typing --> Online: Ngừng gõ > 3s
    Typing --> Online: Gửi message

Giải pháp scale Presence

Cách naive: mỗi khi user thay đổi status, broadcast cho tất cả friend. Nếu user có 500 friend online → 500 WebSocket push. 1 triệu user đổi status/phút → 500 triệu pushes/phút. Không khả thi.

Cách thông minh — Lazy Presence:

1. Lưu trạng thái vào Redis với TTL (key: presence:{userId}, value: online, TTL: 60s)
2. Heartbeat mỗi 30s refresh TTL — nếu hết TTL, tự động chuyển offline
3. Chỉ query presence khi user mở conversation, không broadcast toàn bộ contact list
4. Subscribe presence changes của visible contacts qua Redis Pub/Sub channel

Push Notification cho Offline Users

Khi receiver offline, message được persist vào database và trigger push notification qua FCM (Android) hoặc APNs (iOS). Thiết kế cần lưu ý:

• Batching: Gom nhiều tin nhắn thành 1 notification nếu đến trong khoảng ngắn ("Bạn có 5 tin nhắn mới từ Anh Tú")
• Priority: Tin nhắn 1:1 → high priority (hiển thị ngay), group chat → normal priority (có thể bị delay bởi OS)
• Unread sync: Khi user mở lại app, Sync Service pull tất cả tin chưa đọc từ database, không dựa vào push notification
• Deduplication: Client dùng messageId để dedup — nếu đã nhận qua WebSocket rồi thì bỏ qua notification

End-to-End Encryption (E2EE)

E2EE đảm bảo chỉ sender và receiver đọc được nội dung tin nhắn — server chỉ thấy ciphertext. WhatsApp, Signal dùng Signal Protocol (Double Ratchet Algorithm + X3DH key agreement).

sequenceDiagram
    participant A as Alice
    participant S as Server
    participant B as Bob

    Note over A,B: Key Exchange (X3DH)
    A->>S: Đăng ký Identity Key + Signed Pre-Key + One-time Pre-Keys
    B->>S: Đăng ký Identity Key + Signed Pre-Key + One-time Pre-Keys

    A->>S: Request Bob's Pre-Key Bundle
    S-->>A: Bob's keys (Identity + Signed Pre + One-time)

    Note over A: Tính Shared Secret từ
X3DH key agreement

    A->>S: Encrypted message (ciphertext)
    S->>B: Forward ciphertext
    Note over B: Tính Shared Secret
→ Decrypt message

    Note over A,B: Double Ratchet: mỗi message
dùng key khác nhau

Scaling Strategies

WebSocket Gateway Scaling

WebSocket gateway là stateful (giữ connection), nên không thể scale đơn giản như stateless HTTP service. Chiến lược:

• Horizontal scaling: Thêm server, dùng consistent hashing để phân bổ user. Khi thêm/bớt server, chỉ ~1/N user cần reconnect
• Connection draining: Khi cần shutdown server, báo client reconnect dần (graceful) thay vì cắt đột ngột
• Regional deployment: Deploy WebSocket gateway ở nhiều region, route user đến server gần nhất bằng GeoDNS

Message Database Sharding

graph LR
    subgraph Shard["Sharding by conversation_id"]
        M[Message] --> H{Hash
conversation_id}
        H -->|hash % 4 = 0| S0[Shard 0]
        H -->|hash % 4 = 1| S1[Shard 1]
        H -->|hash % 4 = 2| S2[Shard 2]
        H -->|hash % 4 = 3| S3[Shard 3]
    end

    style H fill:#e94560,stroke:#fff,color:#fff
    style S0 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style S1 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style S2 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style S3 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50

Shard key chọn conversation_id thay vì user_id vì: tất cả message trong cùng conversation nằm trên 1 shard → query "lấy 50 tin mới nhất của conversation X" chỉ hit 1 shard, không cần scatter-gather.

Tech Stack gợi ý cho Production

Monitoring & Observability

Với hệ thống real-time, monitoring là sống còn. Các metric quan trọng cần track:

• Message delivery latency (P50, P95, P99): Thời gian từ khi sender gửi đến receiver nhận — target P99 < 200ms
• WebSocket connection count per server: Alert khi vượt 80% capacity
• Message queue lag: Consumer lag trên Kafka — nếu tăng liên tục là dấu hiệu bottleneck
• Failed delivery rate: Tỷ lệ tin nhắn không delivery được sau 3 retry
• Database write latency: P99 write latency của Cassandra — target < 10ms

Các bài học thực tế từ WhatsApp và Telegram

Tổng kết

Thiết kế hệ thống Chat real-time quy mô lớn đòi hỏi sự cân nhắc kỹ lưỡng ở nhiều tầng: từ WebSocket connection management với consistent hashing và heartbeat, message routing với fan-out strategy phù hợp, database design tối ưu cho write-heavy workload, đến presence system tiết kiệm bandwidth và E2E encryption đảm bảo quyền riêng tư.

Không có giải pháp "one-size-fits-all" — WhatsApp chọn Erlang và fan-out on write vì group nhỏ, Telegram chọn MTProto và hybrid fan-out vì supergroup lớn, Discord rewrite sang Rust vì memory pressure. Điểm chung là: hiểu rõ tradeoff ở từng quyết định kiến trúc, thiết kế cho failure (network partition, server crash), và luôn đo lường bằng metric thực tế thay vì phỏng đoán.

Nguồn tham khảo:

• WhatsApp System Design — System Design Newsletter
• Chat App System Design & Architecture (Complete 2026 Guide) — MirrorFly
• Design a Messaging App Like WhatsApp — Hello Interview
• Messenger System Design is WRONG — andreyka26
• Designing WhatsApp Messenger System Design — GeeksforGeeks