系統設計關鍵數字 (Numbers to Know)
面試不需要背精準數字，但要有「量級直覺」。當你說「需要 sharding」、「需要 cache」、「需要更多 replica」時，要能用數字支撐。
一頁速查表（必背量級）
| 元件 | 核心指標 | Scale 觸發點 |
|---|---|---|
| Cache（Redis） | latency < 1ms、100k+ ops/sec、最高 1TB 記憶體 | hit rate < 80% / latency > 1ms / 記憶體 > 80% / churn |
| Database | 50k TPS 讀、10–20k TPS 寫、64TiB（Aurora 128TiB） | 資料 ≈ 50TiB / 寫入 > 10k TPS / uncached read > 5ms / 跨區域 / 備份時間爆掉 |
| App Server | 連線 100k+、8–64 核心、64–512GB（最高 2TB）、25Gbps | CPU > 70% / latency 超 SLA / 記憶體 > 70% / 頻寬 ≈ 20Gbps |
| Message Queue（Kafka） | 1M msg/sec/broker、latency 1–5ms、儲存 50TB、保存週/月 | throughput ≈ 800k msg/sec / partition ≈ 200k / consumer lag 持續上升 / 跨區域 |
Cache 快取
Redis 早就不是「32GB 小快取」的時代。單節點可達 TB 級，讓「全資料丟進快取」成為合理選項。
- 記憶體上限：1TB（特殊配置更多）
- Latency：同區讀 < 1ms、跨區寫 1–2ms
- 吞吐量：單節點 100k+ ops/sec 讀、寫入也可達數十萬
何時需要對 Cache 動刀（sharding / 多節點）
- 資料集逼近 1TB
- 長期 ops/sec > 100k
- 讀 latency 需要穩在 0.5ms 以下
ops/sec = 硬體 + 軟體 + workload 共決。
- DB：每秒能跑多少 query
- App：每秒能服務多少 API request
- Cache：Redis 每秒能回多少 GET/SET
同一台機器跑 KV lookup 可能 100k ops/sec、跑複雜 JOIN 可能只剩 1k ops/sec。
Database 資料庫
單一 PostgreSQL / MySQL 比想像中能扛——數十 TB 資料、毫秒級 latency、單機數萬筆寫入/秒並不誇張。很多時候限制是備份/跨區複寫，不是效能。
- 儲存：64TiB（Aurora 可到 128TiB）
- Latency：cache 讀 1–5ms、disk 讀 5–30ms、commit 5–15ms
- 吞吐量：Aurora/RDS 單節點 50k TPS 讀、10–20k TPS 寫
- 連線數：5,000–20,000
何時真的需要 Sharding
| 觸發點 | 數字 |
|---|---|
| 資料規模 | ≈ 50TiB |
| 寫入吞吐 | 長期 > 10k TPS |
| 未快取讀取 | < 5ms 需求 |
| 跨區域 | 需要多 region 部署 |
| 備份 | 時間過長或不可行 |
500GB / 1–2TB 就喊 sharding 通常是過度設計。Sharding 之前的優化階梯：
- 慢查詢 → index、SQL 調校
- 讀取瓶頸 → 加 cache → 加 read replica
- 寫入瓶頸 → 調 DB 參數 → 升級硬體
- 以上都用盡 → 才談 sharding
Sharding 主要解決寫入擴展（寫只能走 primary），代價是巨大的複雜度（跨 shard 查詢、分散式交易、資料遷移）。
Application Server 應用伺服器
現代伺服器資源遠超想像。第一個瓶頸通常是 CPU，不是記憶體或連線數。
- 連線數：單機 100k+
- CPU：8–64 核心 @ 2–4 GHz
- 記憶體：64–512GB（最高 2TB）
- 網路：25Gbps
- 啟動時間：Container app 30–60 秒
Scale Triggers
- CPU 長期 > 70–80%
- Latency 超出 SLA
- 記憶體 > 70–80%
- 頻寬逼近 20Gbps
可以直接用來做 cache / 計算 / session 管理。第一個瓶頸通常是 CPU。
Message Queue 訊息佇列（Kafka）
已經從「async 背景處理工具」演變成資料流的骨幹。Latency 5ms 內，甚至可以放進 synchronous API 流程；保存能力近乎無限（週、月）。
- Throughput：1M 訊息/秒/broker
- Latency：1–5ms（同區）
- 訊息大小：1KB–10MB
- 儲存：單 broker 50TB
- 保存期：週/月
Scale Triggers
- Throughput 逼近 800k msg/sec
- Partition 數逼近 200k
- Consumer Lag 持續增加
- 需要跨區域 replication
面試怎麼用這些數字
只要記住三件事：
- Latency 順序：memory ≪ disk ≪ network
- 單機容量：大概能扛多少 QPS、多少 memory
- 資料量級感：1KB / 1MB / 1GB 的差異
說的時候用「大概量級 + 推理」就好：
「假設一台機器有幾十 GB memory，大概可以放幾億個這種 object」
「大概超過多少 TPS 才需要考慮 database sharding」
最常犯的錯：只有幾 TB 資料、幾千 QPS 就急著喊 sharding / 微服務。面試官（特別是 Senior+）會欣賞「根據數據做合理判斷」而不是「盲目套 fancy words」。