🎯 什麼情境該想到我
當你要快速判斷「這系統大概多大、需要什麼量級的資源/架構」時（設計前的粗估）。
⚙️ 怎麼用
- 從使用者/流量推 QPS：日活 × 每人操作數 ÷ 86400 ≈ 平均 QPS；尖峰再 ×2~10。
- 估儲存：每筆資料大小 × 筆數 × 保存年限；別忘副本與索引開銷。
- 估頻寬：QPS × 每次回應大小。
- 記幾個關鍵數字（延遲級距）：記憶體讀 ~100ns、SSD ~100µs、磁碟/網路跨機房 ~ms；讀記憶體比讀磁碟快上萬倍。
- 只求數量級：目的是判斷「單機夠不夠、要不要分區/快取」，不是精算。
★ 書中的範例：估算推特的 QPS 與儲存量
《系統設計面試》第 2 章的練習（書中特別聲明數字僅供練習，不是推特的真實數據）：
假設：3 億月活躍使用者、50% 每天使用、平均每人每天發 2 則推文、10% 的推文含媒體、資料保存 5 年。
QPS：
- 日活躍使用者 = 3 億 × 50% = 1.5 億
- 推文 QPS = 1.5 億 × 2 ÷ 24 小時 ÷ 3600 秒 ≈ 3,500
- 尖峰 QPS = 2 × QPS ≈ 7,000
媒體儲存（媒體平均 1 MB）：
- 每天 = 1.5 億 × 2 × 10% × 1 MB = 30 TB／天
- 5 年 = 30 TB × 365 × 5 ≈ 55 PB
書給的技巧：四捨五入近似（99987 ÷ 9.1 → 100,000 ÷ 10）、寫下假設、標上單位（「5」是 5 KB 還是 5 MB？）。書強調估算重在過程，不在結果。
★ 心算捷徑
| 捷徑 | 數值 | 用法 |
|---|---|---|
| 一天的秒數 | 86,400 ≈ 10⁵ | 每天 X 次 → QPS ≈ X ÷ 10⁵。1 億次／天 ≈ 1,000 QPS |
| 一個月的秒數 | ≈ 2.5 × 10⁶ | |
| 一年的秒數 | ≈ 3 × 10⁷ | |
| 2¹⁰ | ≈ 10³（1 KB） | 2³⁰ ≈ 10⁹（1 GB），2⁴⁰ ≈ 10¹²（1 TB） |
★ 可用性的「幾個 9」：自己算得出來
一年 = 365 × 24 = 8,760 小時；一個月 ≈ 730 小時。
| 可用性 | 每年停機 | 每月停機 |
|---|---|---|
| 99% | 87.6 小時（約 3.65 天） | 約 7.3 小時 |
| 99.9% | 約 8.76 小時 | 約 43.8 分鐘 |
| 99.99% | 約 52.6 分鐘 | 約 4.4 分鐘 |
| 99.999% | 約 5.26 分鐘 | 約 26 秒 |
推論：99.99% 代表每月只有 4 分鐘的預算——任何需要人工介入的故障都會超標（光是收到告警、登入、看儀表板就不只 4 分鐘）。所以四個 9 以上必須靠自動故障轉移。
串聯的服務可用性相乘：A（99.9%）呼叫 B（99.9%）→ 整體最多 99.8%。十個 99.9% 的依賴串起來 ≈ 99.0%。
★ 延遲數字的相對量級
書引用 Jeff Dean 2010 年公布的數字，並提醒有些已經過時，但相對快慢仍有參考價值。書整理出的結論：
- 記憶體很快，磁碟很慢。
- 盡量避免磁碟尋道。
- 簡單的壓縮演算法很快。
- 可能的話，資料在網路傳輸前先壓縮。
- 資料中心通常在不同地區，跨地區傳資料需要時間。
★ 估算完之後的用途：換算成架構決策
| 估算結果 | 架構推論 |
|---|---|
| 寫入 QPS ≈ 7,000 尖峰 | 單一 PostgreSQL 主機可能撐得住，但要實測；再大一個量級就要考慮分片 |
| 30 TB／天的媒體 | 不可能放資料庫 → 物件儲存 + CDN |
| 55 PB／5 年，再乘上副本數（例如 3 份） | 儲存成本是主要的費用項目 → 考慮冷熱分層 |
| 讀取量是寫入的 100 倍 | 快取優先；熱門內容 20% 的資料通常承擔大部分讀取，快取大小可以用這個比例估 |
最常被忘記的三個乘數：副本數（通常 ×3）、尖峰係數（×2 到 ×10）、成長率（明年的量）。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 估算是為了「選對量級的架構」；別在面試/設計初期糾結精確數字。
🔗 相關工具
- 工具-系統設計思考框架 —— 上位流程，估算是它第二步的固定動作
- 工具-資料分區 —— 估算結果的直接用途：算出單機裝不下，就知道非分區不可
- 工具-時間複雜度分析 —— 姊妹尺，一個估系統資源量級，一個估演算法成長速度