動態取樣

流量超過閾值時自動降低取樣率。平時 100% 收集、超載時降到 10% — 仍有資料可分析，只是精度下降。

觸發條件

取樣的公平性

動態取樣不應該只丟新事件保留舊事件（FIFO 丟棄）— 這會讓取樣偏向「burst 初期的事件」。更好的策略是隨機取樣（每個事件有 sampling_rate 的機率被保留），讓取樣後的資料仍然能代表整體分佈。

取樣後的事件帶 _sampling_rate 欄位，分析時用 1 / sampling_rate 做加權還原。

事件優先級

不同事件類型的 debug 價值不同。超載時先丟價值低的，保留價值高的。

優先級的判斷原則：「這個事件丟了、要花多少時間從其他來源補回相同資訊」。Error 的 stack trace 丟了幾乎不可能從其他來源補回；event 的 click 計數可以從後續資料的趨勢推測。

功能降級

非核心功能暫時關閉或降低更新頻率，把資源留給核心功能。

降級的觸發和恢復應該自動化 — 用 collector 的內部 metric（goroutine pool 使用率、寫入延遲）作為訊號。

聚合前移

讓 SDK 端做預聚合，減少送到 collector 的事件數量。

平時：每次 click 送一筆 button.clicked 事件 → 100 次 click = 100 筆事件。 聚合前移：SDK 累積 10 秒內的 click → 送一筆 button.clicked 帶 count: 17 → 100 次 click = ~10 筆事件。

聚合前移犧牲的是事件粒度（失去每次 click 的精確時間戳），換取的是 10x 的事件量減少。適用於高頻但單筆資訊量低的事件（click、scroll、mousemove）。

聚合前移的觸發也可以是動態的 — collector 回 429 時 SDK 自動啟用聚合前移，流量恢復後關閉。

下一步路由

• 突發流量的分類 → 突發流量的分類
• Queue 做更大規模的緩衝 → Queue 緩衝
• 不同規模的應對方案 → 規模分級應對表
• 背壓和 rate limit 的基礎 → 模組三 流量管控

待寫章節

• 突發流量的分類（可預期 vs 不可預期、持續時間和倍率）
• 降級策略（動態取樣、事件優先級、功能降級、聚合前移）
• Queue 緩衝（Kafka / NATS / Redis Streams 做 burst buffer）
• 規模分級應對表（自用 → 中型 → 大型 → 商業網站）

跨分類引用

• ← devops 模組三 流量管控：背壓和 rate limit 是突發應對的基礎元件
• → monitoring 模組四 Collector：Collector 的 ingestion scaling 是本模組的應用場景
• → backend 非同步佇列：Queue 的選型和操作實務
• → devops 模組五 容量規劃：預期突發的容量預備
• → 端到端資料完整性：被自己 SDK DDoS 的三種場景

概念位置

降級是可靠性設計的一部分。它和 failover、rate limit、circuit breaker、feature flag、cache fallback、read-only mode 相關，但重點是產品取捨：哪些功能必須保留，哪些功能可以暫時縮小。 可先對照 Delivery Mode。

可觀察訊號

系統需要降級設計的訊號是下游失敗會拖垮核心流程。常見場景包括推薦系統逾時、報表服務過慢、第三方通知失敗、搜尋服務不穩、尖峰流量超過容量。這些場景應先保護登入、瀏覽、下單、付款或資料保存等核心路徑。

接近真實網路服務的例子

活動期間推薦服務延遲升高。商品頁可以先顯示熱門商品或空推薦，讓使用者仍能瀏覽與下單；若商品頁等待推薦結果才回應，推薦服務的延遲會擴散成整站變慢。

設計責任

降級策略要有觸發條件、使用者體驗、資料一致性影響、告警與恢復條件。它也需要演練，因為未演練的降級常在事故中暴露缺少設定、權限、dashboard 或回復流程。