Meta（前 Facebook）的 System Design 面试在大厂里偏"产品型"——很少出 generic 题（"design a search engine"），更多围绕自家核心产品（News Feed、Stories、Live Comments、Notification、Messenger）。本文聚焦三类最常出现的题型，给出 Meta 八步法下的标准答题路径 + 容易被打成 lean no hire 的硬伤点。
Meta 八步法（速记）
- 澄清需求（DAU / QPS / 读写比）
- API 设计
- 数据模型
- High-Level 架构
- 存储选型（MySQL / Cassandra / Memcached / 拍 TAO）
- 关键路径 walk-through
- 取舍与瓶颈
- 监控 + 容灾
下面把三道题套进这个框架。
题型一：Design News Feed
澄清需求
- DAU：~3B
- 平均 follower：~300
- 高 fanout user：~10M follower
- 读：写 ≈ 100:1（peak 时段）
- 一致性：弱一致即可，新 post 1–3 秒内出现可以接受
API
POST /feed/post {user_id, content, media[]}
GET /feed?user_id=&cursor=
数据模型
| 实体 | 字段（关键） | 存储 |
|---|---|---|
| Post | post_id, author_id, content, ts, media_url | TAO + Blob |
| Follow | follower_id, followee_id, ts | TAO |
| Feed | user_id, post_id, score, ts | Memcached + offline store |
High-Level 架构
client → API GW → Feed Service → [Cache: Memcached]
↓
Feed Builder (offline)
↑
Post Service → TAO + Blob
Follow Service → TAO
关键取舍：Fan-out on Write vs Read
| 模式 | 适合谁 | 缺点 |
|---|---|---|
| Fan-out on Write（push） | 普通用户 | 高 fanout 用户写一次要 fanout 10M 次 |
| Fan-out on Read（pull） | 高 fanout 用户（celebrity） | 读时延高 |
| Hybrid | Meta 的实际方案 | 复杂度上升，但读写都可接受 |
Hybrid 规则：follower > 阈值（如 1M）的用户走 pull，否则 push。
必须能讲清的细节
- Memcached 的 lease get / lease set：避免 thundering herd
- mcrouter 的 routing + replication
- TAO 的写后读一致性：Master region + read-through cache
- 排序算法：EdgeRank（recency × affinity × weight）
容易踩雷
- 只讲 push 不提 pull / hybrid
- Memcached 说成 Redis（Meta 不主用 Redis）
- 没考虑 hot key（celebrity post）
题型二：Design Live Comments
Facebook Live / Instagram Live 下面的实时评论流。
澄清需求
- 同时观看一场直播的用户：可达 10M+
- 评论 QPS：单场峰值 100K+
- 延迟要求：评论从发出到所有观众看到 < 1 秒
- 评论本身写入持久化要求低（不要求所有评论永久保存）
推送选型
| 方案 | 优点 | 缺点 |
|---|---|---|
| Polling | 简单 | 延迟 + 带宽浪费 |
| Long Polling | 节省带宽 | 服务器连接数高 |
| WebSocket | 真正双向、低延迟 | 连接管理 + 重连复杂 |
| Server-Sent Events | 单向，简单 | 不支持二进制 |
Meta 实际方案：WebSocket，配合 MQTT-like 协议。
High-Level 架构
client ⇄ Edge WS Server (region) ⇄ Pub/Sub (Kafka-like)
↓
Comment Service → Hot Storage (Memcached/Redis)
↓
Sampling / ML → Cold Storage
关键设计点
- 分片：按
live_id哈希到不同 pub/sub channel - 背压：评论速率 > 阈值时降采样（用户层无感）
- Reconnect：客户端断线后用 cursor 续传
容易踩雷
- 用 HTTP polling 而不讨论 WebSocket
- 说存全部评论到 MySQL（量级会爆炸）
- 没考虑 spam / 限流
题型三：Design Notification System
Like / Comment / Mention / Friend Request 等 in-app + push notification 统一系统。
澄清需求
- 类型：in-app, push（APNs/FCM）, email
- 用户偏好：每种类型可关 / 可静音
- 量级：每天 ~10B notifications
- 去重 + 聚合（10 人 like 同一个 post 不要发 10 条）
High-Level 架构
Event Source (post like/comment) → Notification Producer → Kafka
↓
Notification Service (workers)
↓
┌───────────────────┬────────────────────┐
APNs/FCM Email Service In-app store
关键设计点
| 维度 | 设计 |
|---|---|
| 去重 | Window-based: 相同 (target_user, event_type, source_id) 5 分钟内合并 |
| 聚合 | "X, Y and 8 others liked your post" |
| 用户偏好 | 进 Notification Service 前查 preference cache |
| 限流 | 按 target_user_id 限速，防止滥发 |
| 重试 | Exponential backoff，超过阈值进 DLQ |
容易踩雷
- 没讲去重 / 聚合（Meta 这块特别看）
- 没考虑 APNs 限流（同一个 device token 高频发会被苹果暂时 ban）
- 没设计 user preference check
高分答题模板：每个题型 3 件事
- 画对架构图（5 个 box 内，不要堆 30 个组件）
- 讲清一个 critical path（end-to-end 一笔走完）
- 明确写出取舍（"X is faster but uses more memory" 这类）
我们见过的 SD 面试高分案例
oavoservice 学员里拿到 Meta SD strong hire 的，普遍特征是45 分钟内主动覆盖到 4–6 个取舍 + 至少 1 个 critical path 的深挖。我们 VO辅助 流程会针对每道题做 mock + 录像复盘 + 标记 hire / no hire 信号点。
具体方案与报价，加微信 Coding0201 沟通。
FAQ
Meta SD 一定考自家产品吗？
约 80% 是。剩下 20% 是 chat、url-shortener 等通用题。但即使通用题，面试官也喜欢拿 Meta 实际架构对比。
不熟悉 Memcached 怎么办？
至少能讲清Memcached vs Redis 的取舍：Memcached 多线程、纯 LRU、无持久化；Redis 单线程（核心）、复杂数据结构、持久化选项多。
应该自己画图还是让面试官画？
你画。Meta SD 面试官通常给一个白板工具（Excalidraw / 自建），你必须主动用。
Mid-level 和 Senior 的 SD 区别？
Mid（E4）能答到 high-level + 1 个取舍就过线，Senior（E5+）必须深入 storage selection + capacity estimation + failure mode。
正在准备 Meta / Google / Amazon 等大厂 System Design 面试？
oavoservice 长期追踪头部公司 SD 真题与评分标准。mentor 来自一线 Staff / Senior SWE，可提供 Meta 自家产品题专项、八步法 mock、storage 选型训练、capacity estimation 加强 等 VO辅助 服务。
👉 立即添加微信：Coding0201，获取 Meta System Design 完整备考方案。
联系方式
Email: [email protected]
Telegram: @OAVOProxy