系统设计面试：设计WhatsApp
「设计WhatsApp」考察的是大规模下的实时传递、持久化的消息存储、在线状态（在线/最后在线时间），以及让数亿台设备保持连接这一连接管理问题。和往常一样，面试官想要的是你的推理和权衡取舍，而不是真实系统的复刻。
按部就班地推进：先明确需求，再估算规模，设计连接与传递路径，决定消息如何存储，然后处理群聊以及离线传递、顺序性这类棘手的边界情况。下面的讲解遵循这条路径。
1. 明确需求
先固定范围。核心是带有可靠传递的一对一消息；要明确群聊、媒体和端到端加密是否在本轮的范围之内。
- 功能性：发送/接收消息、送达与已读回执、在线状态、群聊、收件人离线时的离线传递。
- 非功能性：低延迟、高可用性、持久性（不丢失消息）、同一对话内的顺序性。
- 需要澄清：端到端加密与媒体处理——提及它们，并明确说明是否纳入范围。
2. 估算规模
确定驱动设计的数字。假设约20亿用户，每天产生数百亿条消息；在峰值时相当于每秒数十万条消息，以及数亿台同时在线连接的设备——连接管理本身就成了一个一流的问题。
3. 连接与传递路径
消息传递需要持久连接，而不是请求/响应式的轮询。设备保持一条到网关服务器的WebSocket连接。必须有一个中心组件知道每个用户的连接当前由哪个网关持有，这样消息才能被路由到正确的服务器。
- WebSocket网关：维持设备的活跃连接，处理发送/接收。
- 会话/状态注册表：将用户映射到当前的网关服务器（例如存在Redis中），在连接/断开连接时更新。
- 消息路由：发送方的网关查找接收方的网关并转发；如果对方离线，消息会被加入队列。
4. 消息存储与离线传递
消息必须在接收方断线的情况下依然保留。将每条消息持久化保存，并按接收方跟踪送达状态；如果接收方在线就立即送达，否则先存储，等其重新连接后再转发（store-and-forward）。
以对话为键、写入密集的访问模式，更适合使用类似Cassandra这样的宽列存储（高写入吞吐量、水平扩展），而不是单一的关系型数据库。一旦某条消息被确认送达给所有接收方，就可以将其删除或让其过期，因为WhatsApp不会在服务器端无限期保留已送达的消息。
5. 群聊
群组消息本质上是一种扇出：一次发送变成N次送达。对于常见的群组规模，写时扇出（fan-out-on-write，即推送到每个成员的传递路径）实现简单、读取迅速。要注意其权衡——非常大的群组会让写时扇出的成本变得很高，这也是为什么超大型广播群组是一个不同的设计问题。
6. 需要说出来的权衡取舍
最后点明这些张力：顺序性（按对话的序列号与全局顺序之间的取舍）、回执的一致性与可用性（「最后在线时间」用最终一致性即可，送达确认则需要更强的一致性），以及群组场景下写时扇出与读时扇出的取舍。明确说出这些权衡，才能让答案显得老练。
借助实时辅助练习WhatsApp的系统设计
Natively的系统设计面试助手可以在实际面试中帮你保持结构清晰——实时建议接下来该覆盖哪个维度，并呈现权衡取舍，一切都在你自己的设备上完成。
