題幹與適用場景
你負責資料平台，接收使用者行為事件並供多個消費者即時處理。流量平時平穩、活動期間突增，業務不能接受持續節流，也不想為低谷預付過多容量。假設可以讀取生產者吞吐、讀取延遲、節流與消費者積壓指標，並能在維護窗口切換容量模式。
面試官考察點
面試官關注你是否理解容量模式改變的是營運責任與成本模型，而不是交付語意。強回答會先用歷史峰值和突發形狀判斷是否需要自動擴展，再核對單一分片吞吐邊界、消費者數量、重試與積壓恢復；普通回答只說「流量波動就選隨需」。
回答前需要澄清的問題
- 峰值持續多久，是否可預測？短促且不可預測的尖峰更適合自動管理容量。
- 寫入與讀取是否同時受限？寫入、讀取、記錄數與消費者模型要分別測量。
- 是否存在嚴格成本上限或容量預算？預算緊張且流量穩定時，預置模式更容易最佳化。
- 消費者是共享吞吐還是需要獨占讀取？多個消費者會改變讀取配額與成本。
- 是否允許切換期間短暫更新狀態？切換與突發重試需要明確運行手冊。
30 秒回答框架
「我先按小時統計寫入 MB/s、記錄數、讀取 MB/s、積壓與節流，區分可預測峰值與突發峰值。穩定且可預測的流量用預置容量並預留擴縮容窗口；不可預測尖峰用隨需模式，但要驗證自動擴展爬升、成本與配額。無論選哪種，都以節流率、積壓恢復時間、端到端延遲與月度成本做灰度驗收。」
分步驟深入解答
- 建立容量基線。 將寫入與讀取按分鐘聚合，標記 P50、P95、P99、峰值持續時間與熱點分區鍵；平均值不能代表尖峰。
- 核對吞吐邊界。 AWS 文件給出的預設分片上限是每秒寫入 1 MB 或 1000 筆記錄、讀取 2 MB；分別計算記錄大小與批次請求壓力。
- 選擇模式。 穩定負載可用預置模式配合擴縮容計畫；負載變化快或難以預測時優先隨需模式，並記錄模式自動調整延遲。
- 評估消費者。 共享讀取、增強型扇出、重試與重複消費會影響讀取配額；消費者積壓必須納入容量，而非只看生產端。
- 建立成本模型。 對預置模式計算分片小時與擴縮容餘量，對隨需模式計算實際吞吐與峰值帳單；把重放與突發雙寫列入情境。
- 灰度與回滾。 選擇一個非關鍵流先切換，觀察節流率、積壓恢復、P99 延遲與月度成本；越過護欄時回到已驗證模式並保留資料順序與重試策略。
替代方案包括拆分熱點分區鍵、批次寫入、降低事件大小、使用 Firehose 做緩衝，或為可預測活動提前擴容。容量模式不能修復分區鍵傾斜、慢消費者或無限重試。
高品質示範回答
「我會先查看過去 30 天每分鐘寫入與讀取曲線，算出 P95/P99、峰值持續時間與分區鍵傾斜。按 AWS 的分片邊界把記錄大小折算為寫入 MB/s 與記錄數，再檢查消費者共享吞吐與積壓恢復。若峰值可預測且持續數小時，我會用預置容量加活動前擴容；若峰值短促且無法預測，我會用隨需模式，但先在非關鍵流灰度，要求節流率低於 0.1%、積壓恢復 p99 小於 5 分鐘、端到端延遲不超過基線 20%，並設月度成本上限。任何模式都要監控熱點分區和重複消費，否則換模式只會掩蓋根因。」
常見錯誤
- 錯誤表現： 只用平均吞吐估算 → 失敗原因： 尖峰與熱點分區會造成局部節流 → 修正方法： 使用 P95/P99、峰值持續時間與分區鍵分析。
- 錯誤表現： 把隨需模式當成無限吞吐 → 失敗原因： 仍受服務配額與擴展過程影響 → 修正方法： 驗證爬升、配額與突發測試。
- 錯誤表現： 只算生產端成本 → 失敗原因： 消費者、重試與重放也會放大吞吐 → 修正方法： 建立端到端成本情境。
- 錯誤表現： 忽略資料語意 → 失敗原因： 容量模式不改變至少一次投遞與重複處理風險 → 修正方法： 保留冪等、檢查點與積壓恢復設計。
追問及應對
隨需模式仍然節流，先調什麼？
先區分總吞吐不足、熱點分區鍵與單一消費者落後；檢查寫入記錄數、分區鍵分布與擴展事件，再決定限流、重分區或增加消費者。
什麼時候預置容量更便宜？
當寫入與讀取曲線穩定、峰值可提前安排且長期利用率高時，按分片小時與擴縮容餘量建模；不要只比較單價。
活動流量翻十倍怎麼辦？
先驗證隨需模式的服務配額與歷史爬升能力；對可預測活動提前擴容，設定生產者退避與消費者積壓告警，並準備降級非關鍵事件策略。
如何證明選型正確？
用灰度前後同口徑比較節流率、積壓恢復 p99、端到端延遲、重複率與月度成本；連續兩個業務週期達標後再推廣。