為什麼面試官問系統設計
系統設計題考的不是「你記不記得 Kafka 的架構」，而是：
- 你能不能在模糊條件下做決策
- 你能不能說出 trade-off 而不是「哪個比較好」
- 你能不能估算量級（不需要精確，但要知道 10K RPS vs 10M RPS 的設計完全不同）
框架：5 個階段
1. 需求澄清（5 分鐘）
題目故意模糊，面試官要看你會不會問對問題：
功能性需求：
- 「這個系統的核心用例是什麼？前 3 個最重要的功能是什麼？」
- 「讀多還是寫多？讀寫比例大概是多少？」
- 「有沒有實時需求？還是 eventual consistency 可以接受？」
非功能性需求：
- 「預計多少 DAU / MAU？」
- 「latency 要求？可以接受幾秒？」
- 「data 要保留多久？有沒有法規合規要求？」
範圍確認：「我打算先設計 X 功能，Y 先不做——這樣可以嗎？」
2. Back-of-Envelope 估算（5 分鐘）
估算的目的是決定架構的量級——不需要精確，差一個量級就要設計不同。
常用數字：
DAU 1 千萬，平均每天 10 個操作 → QPS ≈ 10M × 10 / 86400 ≈ 1,157 QPS（平均）
峰值通常是平均的 3~5 倍 → 峰值 ≈ 5,000 QPS
儲存估算：
每則貼文 1 KB，每天 100 萬則 → 每天 1 GB → 3 年 ≈ 1 TB
記憶體估算：
Redis 快取最熱 20% 的資料，假設 10M 筆 profile，每筆 500 bytes
→ 10M × 500B × 20% = 1 GB cache size
這些數字決定：用單機還是分散式？用 SQL 還是 NoSQL？需不需要 CDN？
3. 高層架構（10 分鐘）
先畫 happy path——不要一開始就深入細節。
基本架構骨架：
Client → Load Balancer → App Server → DB
↓
Cache
↓
Message Queue → Worker
從這個骨架開始，根據需求補：
- 讀多？→ 加 Read Replica 或 Cache 層
- 寫入密集？→ 考慮 Message Queue buffering
- 有文件 / 圖片？→ 加 Object Storage（S3）+ CDN
- 跨地區？→ 加 CDN + 多 region deploy
4. 深入設計（15 分鐘）
面試官通常會挑 1-2 個子系統深入。常見要深入的區域：
API 設計：
POST /v1/tweets → 發文
GET /v1/tweets/{id} → 取單篇
GET /v1/users/{id}/feed → 取 timeline
資料庫 Schema：
- 用 SQL 還是 NoSQL？為什麼？
- 怎麼分 Shard？Shard key 選什麼？
- 哪些欄位要 Index？
Scale 瓶頸：
- 哪裡會先爆？→ DB 寫入？→ 主從延遲？→ Cache 命中率？
- 怎麼解？→ Read Replica → Sharding → CQRS
5. 進階討論（5 分鐘）
如果時間允許，面試官可能問：
- 「如果流量突然 10x，你怎麼處理？」
- 「如果要支援全球不同 region 的用戶？」
- 「這個設計的最弱點是什麼？」
常見題型拆解
Feed / Timeline 系統（Twitter、Facebook）：
- Fan-out on write（預先推）vs fan-out on read（讀時拉）
- 關鍵：celebrity 用戶有 1 億個 follower，fan-out on write 會爆
短網址系統（TinyURL）：
- Hash 選擇（base62 of 7 chars = 3.5 trillion unique URLs）
- 301 vs 302 redirect（cache 行為不同）
Rate Limiter：
- Token Bucket vs Sliding Window
- 分散式 rate limiting 需要 Redis + Lua script 保 atomic
通知系統：
- Push（APNs / FCM）vs WebSocket vs polling
- 送達保證 vs 重複送達處理（at-least-once delivery + idempotency key）
面試常見錯誤
- 跳過估算直接設計：不知道量級，架構選擇無從判斷
- 說「用 Kafka 就好」但說不出為什麼：面試官要的是 trade-off，不是技術名詞
- 設計完美系統：每個點都深入，時間不夠；面試官更想看廣度的清晰，不是某個角落的深入
- 不主動說自己的假設：「我假設 95% 的流量是讀」——說出你的假設，讓面試官修正