一、复习指南

希望看到这篇笔记的你能顺利拿下理想的offer。Meta 的 system design 面试有着非常清晰的出题规律：数据强一致、系统低延迟、功能对齐产品体验。无论题目表面看似社交、内容分发或存储系统，面试的核心考察永远围绕三个维度展开——用户规模（scale）、一致性策略（consistency tradeoff）、以及系统的演进能力（evolution & extensibility）。

复盘一题的正确姿势是：首先，明确系统的用户操作路径，用一句话定义“核心交互”；其次，估算 QPS、存储与延迟预算；再者，画出数据流与控制流（write path 和 read path），识别缓存、数据库与消息系统之间的边界；最后，通过一到两个权衡点展开深度讨论，例如“read-fanout 与 write-fanout”、“push 与 pull”、“cache invalidation 与 eventual consistency”。Meta 的面试官往往在这最后的 tradeoff 环节决定候选人的面试结果。下面我们讨论几个Meta超高频的SD真题。

二、超高频题：Instagram / Newsfeed 系统

Feed 系统是 Meta 面试的经典高频题，它考察的核心是fanout 与实时性权衡。在产品层面，一个用户发帖，意味着几百万个粉丝的 timeline 需要更新；在系统层面，这对应一次写入触发大量下游数据变动。

Meta 的设计传统是 push + pull 混合模型。对于高活跃用户（例如名人账号），系统只在写入时做轻量 fanout，将帖子存入 global post store；读取时由 follower 的 newsfeed 服务执行 lazy pull 聚合。对于普通用户，则在写入时直接 fanout 到 followers 的 feed inbox，以换取快速读取体验。所有 timeline cache 层（通常部署在 Memcache 或 TAO 之上）都遵循 TTL + version invalidation 策略，保证浏览时延不超过 100ms。

面试中需特别强调 ranker pipeline 的解耦。Meta 的新闻流 ranking 是多模型协作的——一个快速排序模型在 serving 层执行，另一个复杂的 ML 模型在离线训练中更新特征与权重。展示这一点，能体现对 production-scale system 的理解深度。

三、超高频题：Chat System（Messenger / WhatsApp）

Chat 题的考点集中在消息一致性与 delivery semantics。Meta 的即时通讯系统采用 multi-device synchronization model，要求消息在不同设备间按时间一致显示，同时保证「已送达」「已读」等状态准确。

设计时首先区分三层语义：conversation service（存储）、delivery service（实时分发）、以及 presence service（在线状态管理）。发送路径中，客户端向 delivery gateway 发起写入，消息被放入 Kafka 或自研的 Scribe 队列，再由多个 consumer 异步推送到接收方。每条消息带有逻辑时钟（Lamport timestamp）或 server-sequenced ID，用于全局排序。

面试官常会追问离线消息如何处理。这时应强调「store-and-forward」机制：如果目标用户离线，delivery service 将消息暂存在 Redis 或持久队列中，并记录 offset；当用户重新上线时，client 会从 offset 处继续拉取，保证不丢不重。最后要讨论 end-to-end 加密与 metadata 解耦，因为 Meta 特别关注安全与隐私合规。

四、超高频题：Ticketmaster / Reservation System

这道题常出现于 Meta 的 infrastructure 或 commerce 团队面试，考察重点是 防止 double booking 的分布式锁设计。面试中要把系统建模为一个「稀缺资源分配问题」：多个用户同时请求同一个座位或房间，系统必须在高并发下保持唯一性。

标准思路是使用 reservation token + TTL-based lock。当用户点击预订时，系统生成一个带过期时间的 token 并写入 Redis，作为 seat_id 的唯一持有者。如果确认购买，系统再将该锁升级为持久状态并写入数据库，否则 TTL 过期自动释放。若面试官追问跨分区一致性，可以进一步说明使用「sharded lock manager」与「version check on write」策略，避免 Redis 宕机导致的 ghost lock。

此外，应展示事务设计的弹性层：下单服务与支付服务通过消息队列（如 Kafka）连接，以实现 eventual consistency。这种解耦方案体现出对「exactly-once semantics」与「idempotent write」的掌握，是高分回答的关键。

五、总结

Meta 的 system design 面试强调「结构完整 + tradeoff 清晰 + scalability 有据」。面试官更关心候选人是否能在复杂系统下保持推理连贯、表达逻辑清楚，而不是是否记住具体组件名称。复习时应着重练习 verbal reasoning：在白板上边画边解释「为什么要这样拆分、这种设计解决了什么问题、又引入了什么新的挑战」