先找出突發流量真正發生的位置
感測資料的尖峰不一定來自裝置突然增加。網路中斷後的集中補傳、韌體更新造成取樣頻率改變、設備重新連線、批次匯入，以及下游資料庫變慢，都可能讓入口流量或待處理佇列快速上升。設計前應分別量測裝置送出速率、閘道器接收速率、訊息平台寫入速率與消費端完成速率；只看 API 每秒請求數，通常無法判斷壓力究竟在哪一層累積。
工程上需要同時描述穩態流量與突發流量。前者決定長期運算與儲存成本，後者決定緩衝空間和恢復時間。還要確認訊息大小、尖峰持續時間、允許延遲、資料保存期限，以及裝置能否重送。若下游處理速度長期低於輸入速度，再大的佇列也只是延後故障；此時必須擴充消費能力、降低輸入量，或改變資料處理方式。
緩衝區必須有界，而且容量要能解釋
緩衝可以放在裝置、邊緣閘道、訊息代理或應用程式內，但不同位置解決的故障不同。裝置端緩衝適合處理短暫斷線，卻受限於儲存空間與寫入壽命；閘道器能彙整多台設備並在本地持久化，但會形成站點級故障點；集中式訊息平台較容易擴充與監控，前提是資料已成功離開現場。應用程式記憶體佇列延遲低，卻不適合承擔需要跨程序重啟保存的資料。
不要把無上限佇列當成可靠性設計。容量應根據最大可接受積壓時間、可用儲存空間和下游恢復吞吐量設定，並預留訊息索引、複本與協定額外負擔。每筆資料還應帶有事件時間、序號或冪等鍵，讓重送不會重複觸發告警或寫入。當佇列接近上限時，系統必須有明確策略，例如拒絕新資料、覆寫最舊資料、只保留摘要，或將低優先資料移到較慢的儲存層。
背壓、限流與降級處理不同問題
背壓是讓上游知道下游已經跟不上；限流是限制某個來源在一段時間內可送入多少工作；降級則是在資源不足時降低處理成本或資料精度。三者常需一起使用。若通訊協定支援確認、流量窗口或延後拉取，可以自然地把消費能力傳回上游；若裝置只會持續推送，則需要由閘道器或接收服務執行有界緩衝與准入控制。
- 依來源限流：避免單一設備、租戶或站點耗盡共用容量，並為重要來源保留額度。
- 依資料類型分級：警報、控制回應與安全事件優先；高頻遙測可延後、聚合或取樣。
- 使用令牌桶處理短暫尖峰：允許有限度突發，同時約束長期平均速率；若不能容忍任何突發，再採用更嚴格的速率整形。
- 設定重試預算：採指數退避並加入隨機抖動，限制次數與總時長，避免故障期間形成重試風暴。
- 提供明確結果：回覆可重試、不可重試或已接受但延後處理，避免上游因不確定狀態重複送出。
捨棄資料時，應依業務語意選擇策略。監控趨勢可能適合保留每個時間窗的最小值、最大值、平均值與最後值；設備告警則通常不能用一般取樣取代。若控制命令與遙測共用管線，至少要分開優先級與佇列，避免大量歷史補傳阻塞即時控制。
用可觀測性與故障演練驗證恢復能力
僅監控 CPU 和記憶體不足以判斷資料管線是否健康。應觀察各階段的輸入與輸出速率、佇列深度、最舊訊息年齡、端到端延遲、拒絕與捨棄數量、重試率，以及各來源的流量分布。佇列深度上升代表正在累積，但最舊訊息年齡更能反映資料是否逐漸失去時效。告警也應區分短暫尖峰與持續性失衡，否則團隊容易對噪音麻木。
上線前應模擬斷線後補傳、下游資料庫降速、訊息代理重啟、單一來源異常暴增，以及消費者部分失敗。測試重點不是只看系統能否撐住尖峰，而是確認過載策略是否依設計啟動、重要資料是否仍能通過，以及流量恢復後積壓能否在可接受時間內消化。若需要跨 LINE、ERP、CRM、雲端平台與現場設備整合，最好由各系統共同定義優先級、冪等規則與失敗責任，避免把壓力單純推向下一個服務。