OfferForge 导师 Dr. W. — 博士毕业，前 FAANG Senior MLE。研究方向为大规模分布式机器学习系统，曾在顶级国际学术会议发表多篇论文。负责团队学术方向把控与 MLE 面试辅导。
OfferForge 导师 Dr. S. — 前大厂 Senior SDE，精通分布式系统与大规模数据处理。曾在顶级技术会议发表多篇技术报告，专注于系统可扩展性与可靠性。负责课程体系设计与 System Design 面试辅导。
OfferForge 导师 Dr. L. — 前大厂 Senior SDE，深耕分布式系统与微服务架构。在服务治理、事件驱动架构方面有丰富实战经验。负责求职策略制定与 SDE 面试辅导，已帮助多位候选人斩获 Senior 级别 Offer。
希望看到这篇笔记的你能顺利拿下理想的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真题。
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 的理解深度。