流量與資料量評估的核心原則是先描述規模形狀，再討論服務能力。平均 QPS、尖峰倍率、資料成長速度、hot key、保留期限與讀寫比例，會直接影響資料庫、快取、queue、觀測與部署平台的選型方向。

本章目標

學完本章後，你將能夠：

1. 區分平均流量、尖峰流量、burst 與批次流量
2. 用讀寫比例、hot key 與資料成長辨識瓶頸形狀
3. 評估資料保留期限與查詢範圍對服務能力的影響
4. 避免用單一數字描述所有容量問題

【觀察】容量問題通常來自形狀差異

容量評估的第一個問題是「壓力如何出現」。同樣是一千個 request，每秒穩定進來、五秒內全部湧入、集中打同一個商品、或每次都查不同使用者，對系統的壓力完全不同。

這張表是評估索引。真正的容量討論要把數字放回產品情境，才能知道需要擴充哪種能力。

【判讀】平均流量決定基礎容量

平均流量的核心用途是估算日常成本與基本容量。穩定 API、背景 worker、資料同步與觀測資料，都需要知道平常每秒會產生多少 request、message、log、metric 或資料寫入。

接近真實網路服務的例子包括：

• 一個 B2B SaaS 白天每秒 50 個 API request，晚上降到每秒 5 個。
• 一個 webhook 平均每秒 20 筆事件，但每筆事件會觸發三個下游工作。
• 一個即時 dashboard 平均每秒收到 200 筆狀態更新。

這類評估的陷阱是只看平均值。平均值能估算基礎成本，但它無法說明尖峰、集中 key、批次匯入或下游失敗時的堆積風險。

【判讀】尖峰流量決定緩衝與降級策略

尖峰流量的核心用途是估算系統如何吸收短時間壓力。活動開賣、推播通知、直播開始、月底結帳、第三方批次同步，都可能讓流量在短時間內暴增。

接近真實網路服務的例子包括：

• 活動開始後前三分鐘的商品頁瀏覽量是平常的 30 倍。
• 推播送出後，大量 client 同時回到 App 查通知列表。
• 每天凌晨外部系統一次送入大量資料檔。

這類評估的陷阱是把尖峰當成一般擴容問題。尖峰可能需要 queue、backpressure、cache warmup、rate limit、預先產生 read model 或降級策略；單純加機器未必能保護資料庫、broker 或外部 API。

【判讀】讀寫比例決定資料路徑設計

讀寫比例的核心用途是判斷主要壓力在讀取、寫入還是交易一致性。讀多系統常需要 cache、read model 或搜尋索引；寫多系統則更關心 transaction、batching、queue、idempotency 與資料成長。

接近真實網路服務的例子包括：

• 商品頁是讀多寫少，資料可短暫快取。
• 訂單建立是寫入與交易一致性重點，狀態轉移要受保護。
• 行為分析事件是寫多讀少，讀取通常集中在離線報表或聚合結果。

這類評估的陷阱是只問資料量。十億筆冷資料和一萬筆每秒被反覆讀寫的熱資料，壓力來源完全不同。讀寫比例要和查詢模式、更新頻率與一致性需求一起看。

【判讀】hot key 會讓平均流量失真

hot key 的核心訊號是壓力集中在少數資料上。即使整體 QPS 看起來正常，單一商品、單一直播間、單一聊天室、單一熱門文章或單一 tenant 也可能打爆特定資料路徑。

接近真實網路服務的例子包括：

• 一個熱門商品承接大部分查詢與庫存扣減。
• 一個大型直播間同時有大量觀眾接收訊息。
• 一個企業 tenant 的使用量遠高於其他 tenant。

這類評估的陷阱是只做整體水平擴展。hot key 可能需要資料拆分、topic 分層、快取策略、讀寫分離、限流或產品層降級；具體做法要等需求形狀確認後再進入服務細節。

【判讀】資料成長與保留期限決定長期成本

資料成長評估的核心問題是「今天可用的設計，三個月後是否仍可用」。row、event、log、trace、object、index 都會成長；不同資料還有不同查詢頻率與保留需求。

接近真實網路服務的例子包括：

• 每天新增一百萬筆行為事件，但只查最近七天即時聚合。
• 每天新增十萬筆付款紀錄，法規要求保存多年。
• 每天產生大量 debug log，但事故排查主要看最近兩週。

這類評估的陷阱是把所有資料都放進同一個保存策略。正式狀態、audit、分析事件、debug log、trace、使用者上傳檔案需要不同保留期限、查詢方式與封存策略。

【判讀】查詢範圍決定索引與讀取模型

查詢範圍的核心問題是「使用者或系統實際會怎麼找資料」。查最近十筆、查單一 ID、查某個 tenant、查全文、查任意時間範圍與查聚合報表，需要不同資料模型。

接近真實網路服務的例子包括：

• 後台訂單頁主要查單一訂單與最近訂單。
• 客服系統需要依 email、電話、交易 ID 找到使用者。
• 分析頁需要依時間、地區、產品線聚合趨勢。

這類評估的陷阱是把所有查詢都塞進正式資料庫的單一模型。當查詢體驗、聚合方式或資料保留策略不同時，可能需要 read model、search index、analytics pipeline 或 archive，但這些都應來自明確查詢需求。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入容量與成本實作章節：

1. 流量形狀是否明確（平均、尖峰、burst、批次）
2. 主要壓力來源是否明確（讀寫比例、hot key、查詢範圍）
3. 成長假設是否明確（資料新增速度、保留期限、查詢頻率）
4. 容量保護策略是否明確（backpressure、rate limit、降級）

下一步建議路由：

• 9.13 擴展軸與 Stateless 前提（流量壓力出來後、選擴展軸）
• 5.9 邊緣分發與靜態資源（讀峰值的第一層緩衝）
• 02-cache-redis
• 03-message-queue
• 06-reliability

小結

流量與資料量評估要描述壓力形狀。平均流量估算基礎容量，尖峰流量決定緩衝與降級，讀寫比例影響資料路徑，hot key 會讓平均值失真，資料成長與保留期限決定長期成本，查詢範圍決定索引與讀取模型。這些資訊補齊後，服務選型才會有可靠依據。