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