腾讯运营着全球最大的即时通讯平台微信，这道题考察候选人对分布式系统、消息队列和大规模实时通信的理解，是腾讯软件工程师的核心能力要求。
先明确规模需求：日活用户数、峰值QPS、消息类型（文字/图片/视频）及投递保障级别。
描述分层架构：接入层（TCP/WebSocket长连接）、逻辑层（消息路由、群聊扇出）、存储层（基于timeline的消息存储）。
解释消息投递模型——群聊场景下写扩散与读扩散的选择，以及利用递增sequence ID实现离线消息同步。
讨论可靠性与一致性：消息ACK机制、幂等投递，以及网络分区和重连场景的处理策略。
我会将系统分为三层设计。接入层基于Epoll的TCP服务器维持客户端长连接，单机支持百万级并发，前置负载均衡器。逻辑层负责消息路由：单聊直接推送至收端所在的连接服务器；群聊对500人以下的小群采用写扩散，大群采用读扩散，在存储开销和读取延迟间取得平衡。存储层采用timeline模型，每个用户维护一个有序收件箱，以单调递增的sequence ID索引，客户端据此高效同步未读消息。消息先写入Kafka保证持久性，再异步落盘到分布式KV存储。高可用方面，采用多机房部署和最终一致性方案，利用CRDT解决并发写冲突。监控体系追踪端到端投递延迟、消息丢失率和连接稳定性。
提及微信已知的技术选型如MMTLS协议和Mars网络库，展示对业务的了解。
用具体数字量化设计，如日均千亿消息，体现对规模的认知。
明确讨论写扩散与读扩散的权衡，说明各自适用场景。
写扩散在发送时将消息复制到每个群成员的收件箱，读取快但大群开销大；读扩散只存一份消息，读取时扇出，节省存储但增加读延迟。微信对500人以下群用写扩散，更大的群用读扩散。
微信使用服务端分配的sequence ID，每条消息获得单调递增的ID，客户端用最后已读的sequence拉取未读消息，确保一致的消息顺序，不依赖客户端时间戳。