我们来设计一个类似 WhatsApp 的即时通讯服务，对标 Facebook Messenger、WeChat。

What is WhatsApp?

WhatsApp 是即时通讯应用，覆盖 180+ 国家、20 亿用户，并支持 web。

Requirements

Functional requirements

一对一聊天
群聊（最多 100 人）
支持文件分享（图片、视频等）

Non-functional requirements

高 availability，低 latency
可扩展、高效

Extended requirements

Sent / Delivered / Read 回执
Last seen
Push notifications

Estimation and Constraints

注意：和面试官确认规模假设。

Traffic

假设 50M DAU，每人每天发 10 条消息给 4 个人，总计 2B messages/day：

$$ 50 \space million \times 40 \space messages = 2 \space billion/day $$

假设 5% 为媒体文件，约 100M files/day：

$$ 5 \space percent \times 2 \space billion = 100 \space million/day $$

RPS

$$ \frac{2 \space billion}{(24 \space hrs \times 3600 \space seconds)} = \sim 24K \space requests/second $$

Storage

消息 100 bytes/条：

$$ 2 \space billion \times 100 \space bytes = \sim 200 \space GB/day $$

媒体文件 100KB/个：

$$ 100 \space million \times 100 \space KB = 10 \space TB/day $$

10 年约 38 PB：

$$ (10 \space TB + 0.2 \space TB) \times 10 \space years \times 365 \space days = \sim 38 \space PB $$

Bandwidth

日入站 10.2 TB：

$$ \frac{10.2 \space TB}{(24 \space hrs \times 3600 \space seconds)} = \sim 120 \space MB/second $$

High-level estimate

Type	Estimate
Daily active users (DAU)	50 million
Requests per second (RPS)	24K/s
Storage (per day)	~10.2 TB
Storage (10 years)	~38 PB
Bandwidth	~120 MB/s

Data model design

users：name、phoneNumber 等

messages：type、content、timestamps、chatID/groupID

chats：一对一聊天

users_chats：N:M

groups：群组

users_groups：N:M

选什么 database？

数据模型看似 relational，但可拆成多个服务各自拥有表，避免单库瓶颈。可用 PostgreSQL 或 Apache Cassandra。

API design

Get all chats or groups

getAll(userID: UUID): Chat[] | Group[]

Get messages

getMessages(userID: UUID, channelID: UUID): Message[]

Send message

sendMessage(userID: UUID, channelID: UUID, message: Message): boolean

Join / Leave group

joinGroup(userID: UUID, channelID: UUID): boolean
leaveGroup(userID: UUID, channelID: UUID): boolean

High-level design

Architecture

采用 microservices：

User Service：auth + user info

Chat Service：WebSockets 连接 + 聊天/群聊逻辑（缓存在线连接）

Notification Service：push 通知

Presence Service：last seen

Media Service：文件上传

Inter-service communication

可用 REST/HTTP 或更高效的 gRPC。需要 Service discovery 或 service mesh。

Real-time messaging

Pull model：Long polling

Push model：WebSockets / SSE

Push 更低 latency、更可扩展，WebSockets 支持 full-duplex。

Last seen

用 heartbeat 写入 cache：

Key	Value
User A	2022-07-01T14:32:50

也可用“最近操作时间阈值”方式判断离线。

Notifications

消息发送后若用户离线，chat service 将事件写入 message queue，notification service 再调 FCM/APNS。

使用 queue 的原因：best-effort ordering + at-least-once delivery。

Read receipts

通过 ACK 更新 deliveredAt / seenAt。

Design

Detailed design

Data Partitioning

Sharding + Consistent hashing。

Caching

只缓存旧消息 + pagination。LRU eviction，cache miss 回源。

Media access and storage

使用 object storage / HDFS。WhatsApp 会在用户下载后删除媒体。

CDN

使用 CDN 加速静态内容。

API gateway

多协议（HTTP/WebSocket）建议用 API Gateway。

Identify and resolve bottlenecks

增强 resilience：

各服务多实例
Load balancers
DB read replicas
分布式 cache 多副本
API Gateway standby
通知系统用 Kafka / NATS
Media 压缩
拆分 group service