封底估算
一句話定義
封底估算是在資訊不完整時，用簡化假設與數量級快速估出 QPS、儲存量、頻寬、延遲、可用性或成本，目的是檢查設計方向是否合理，而不是追求精準數字。
核心要點
估的是數量級，不是精算表
系統設計早期最需要的是判斷瓶頸級別：
- 每天 1 億請求大約是多少 QPS？
- 每張圖片平均 1 MB，10 億張需要多少儲存？
- 高峰是平均的 3 倍還是 30 倍？
- 99.9% 可用性一年大約允許多少停機時間？
- 讀寫比 100:1 時，瓶頸在讀路徑還是寫路徑？
只要能判斷「單機可行 / 需要快取 / 需要佇列 / 需要分片 / 需要 CDN」，估算就已經產生價值。
估算流程
- 寫出假設：DAU、平均操作次數、資料大小、讀寫比、保留時間。
- 換成日 / 秒 / 月尺度：把需求轉成 QPS、每秒寫入量、每日新增資料、總儲存量。
- 拆峰值與平均值：平均 QPS 不代表高峰容量；高峰倍率要明說。
- 檢查瓶頸：CPU、I/O、資料庫、網路、儲存、第三方 API 哪個先爆。
- 回到設計取捨：估算結果應影響架構，而不是成為孤立數字。
面試中的用途
系統設計面試 中，封底估算有三個功能：
- 校準範圍：確認面試官期待的是 10 萬用戶級系統，還是 10 億用戶級系統。
- 暴露瓶頸：讓 cache、queue、sharding、CDN、object storage 等元件有理由出現。
- 展示思考：面試官看的是候選人如何拆問題、做假設、承認不確定性並用估算推動設計。
與商業估算的對位
封底估算與 TAM-SAM-SOM 都是「先用粗估建立判斷邊界」：
| 類型 | 問題 | 產出 |
|---|---|---|
| 封底估算 | 系統容量是否撐得住 | QPS / storage / bandwidth / latency |
| TAM-SAM-SOM | 市場機會是否足夠 | 市場規模 / 可服務市場 / 可取得市場 |
共同原則：估算不是裝精準，而是讓後續設計或決策不漂浮。
與其他概念的關係
- 系統設計 — 系統設計早期的 sanity check。
- 系統設計面試 — 面試中最常被要求公開思考過程的工具之一。
- 可擴展性 — 估算結果決定是否需要水平擴展、快取、分片、佇列或多區部署。
- Goal-Signal-Metric — 兩者都把抽象目標轉成可量測指標；封底估算偏容量與成本，GSM 偏產品與行為指標。
- TAM-SAM-SOM — 商業場景的市場規模估算；可借用「粗估 → 邊界 → 決策」的共同思路。
相關來源
- 2026-05-14-搞定系統設計面試 — 主來源；第 2 章集中介紹封底估算，後續 URL 縮短器、搜尋自動補全、影片分享與雲盤案例也反覆使用。
備註
未來可補：常用 latency numbers、availability nines、storage / bandwidth 速算表、雲成本粗估、queue backlog 算法與 capacity planning 實務。