背壓 vs Rate Limit

背壓和 rate limit 都是流量控制，但觸發邏輯不同：

背壓在系統承載達到上限時才觸發，rate limit 在到達預設上限時就觸發（即使系統還有餘裕）。兩者互補：rate limit 防止單一來源打爆系統，背壓防止所有來源加起來打爆系統。

實作模式

有限 buffer + 回壓訊號

最常見的背壓實作是在處理管線中加一個有限容量的 buffer。Buffer 滿了代表下游處理不完，這時對新請求回傳「忙碌」訊號。

在 Go 的 HTTP server 中，buffer 可以是一個有限容量的 channel：

 1var ingestCh = make(chan Event, 10000) // 有限 buffer
 2
 3func handleIngest(w http.ResponseWriter, r *http.Request) {
 4    event := parseEvent(r)
 5    select {
 6    case ingestCh <- event:
 7        w.WriteHeader(http.StatusAccepted) // 202
 8    default:
 9        w.Header().Set("Retry-After", "5")
10        w.WriteHeader(http.StatusTooManyRequests) // 429
11    }
12}

Buffer 容量的選擇取決於下游的處理速度和可接受的記憶體用量。每個 event 約 1KB 時，10000 容量的 buffer 佔 ~10MB — 對多數服務來說可以接受。

HTTP 429 + Retry-After

HTTP 429 Too Many Requests 是標準的回壓訊號。Retry-After header 告訴 client 多少秒後重試。

Retry-After 的值可以是固定的（如 5 秒），也可以根據 buffer 的填充程度動態計算 — buffer 越滿、Retry-After 越長。

TCP 層的背壓

TCP 協議本身有背壓機制 — 接收端的 receive window 縮小時，發送端自動減速。但 HTTP 層的背壓比 TCP 層更精確，因為 HTTP 可以回傳語意化的狀態碼和 header，client 可以根據語意做出更智慧的回應（如優先重試 error 事件、放棄 event 事件）。

監控系統的應用

監控系統的 collector 是背壓的典型場景：多個 SDK 同時 flush 事件到 collector，collector 的寫入速度（SQLite / PostgreSQL）是瓶頸。

背壓鏈路：SDK flush → collector HTTP endpoint → 寫入 channel（有限容量）→ 寫入 goroutine → storage。Channel 滿時回 429，SDK 的離線 buffer 機制接手 — 事件暫存本地，等 collector 恢復後補發。

這個設計讓 collector 在高峰時不崩潰（有限 buffer 控制記憶體）、SDK 端不丟事件（離線 buffer 暫存）。代價是事件的到達有延遲（Retry-After 時間 + 補發時間）。

下一步路由

• 主動的流量限制 → Rate Limiting
• 依賴服務失敗時的防護 → 熔斷器
• 突發流量時的組合策略 → 模組七 突發流量

待寫章節

• 背壓機制（下游慢時上游怎麼減速）
• Rate Limiting（主動限制每個來源的請求速率）
• 熔斷器（依賴服務失敗時怎麼快速失敗而非拖慢自己）
• Bulkhead 隔離（不同工作負載的資源池隔離）

跨分類引用

• → monitoring 模組四 Collector：Collector 的 ingestion 防護是本模組的應用場景
• → devops 模組七 突發流量：突發流量時這四種機制怎麼組合使用
• → backend 可靠性：熔斷和 bulkhead 也是 backend 的可靠性設計元件

概念位置

背壓位在 SDK 和 collector 之間的 HTTP 通訊層。觸發順序：collector 的寫入 channel 容量耗盡 → HTTP handler 無法送入事件 → 回 429 → SDK 收到 429 → SDK 降低取樣率（從 1.0 → 0.5 → 0.1）。背壓是全域的容量訊號 — 所有 SDK 同時收到，所有 SDK 同時降速。

可觀察訊號與例子

需要關注背壓的訊號是 collector 端的 collector.events.backpressure 計數器持續上升、或 SDK 端的 sdk.sampling.rate 低於 1.0。典型場景：行銷活動導致同時在線使用者暴增 → 所有 SDK 同時 flush → collector channel 瞬間填滿 → 全域 429 → 所有 SDK 動態降採樣。

和 DevOps 背壓的關係

DevOps 流量管控討論通用的背壓概念（TCP flow control、message queue consumer lag、circuit breaker）。本系列聚焦 SDK ↔ collector 之間的具體實作 — HTTP 429 是訊號、動態取樣是回應、Go channel 容量是觸發條件。通用概念在 DevOps 模組，監控場景的具體機制在本系列。

完整章節

背壓在四層防線中的位置（第二層 collector 單機防護）→ Ingestion Scaling。背壓造成的資料損失和控制策略 → 端到端資料完整性。

四層防線

每一層在不同規模觸發，由近到遠依序啟用。前一層能擋住的流量不需要啟用後一層。本章的四層按防線位置劃分（SDK / Collector / 基礎設施兩層）。DevOps 的規模分級應對表按 events/sec 量級劃分（Tier 1-4），兩者視角不同但覆蓋相同的擴展路徑。

第一層：SDK 端的流量控制

流量控制的最有效位置是事件產生的源頭。SDK 端減少的事件量，後面每一層都不需要處理。

動態取樣

SDK 在收到 collector 的 HTTP 429（Too Many Requests）回應時，自動降低取樣率。恢復正常後逐步回升。

1正常 → sampling 1.0
2收到 429 → sampling 降到 0.5
3持續 429 → sampling 降到 0.1
4連續 10 次成功 → sampling 回升到 0.5
5連續 30 次成功 → sampling 回到 1.0

動態取樣的控制邏輯在 SDK 端實作，不需要 collector 端額外支援 — 429 回應碼就是觸發訊號。和感測器生命週期管理的靜態取樣率互補 — 靜態取樣在 config 中設定、動態取樣在執行期自動調整。

聚合前移

SDK 端累積一段時間的同名事件，送出摘要而非逐筆。適合 metric 類的高頻取樣。

例：原本每 100ms 送一筆 render.frame_drop，改成每 5 秒送一筆 render.frame_drop_summary（帶 count + min + max + avg）。事件數從 50 筆/5s 降到 1 筆/5s。

聚合前移犧牲事件粒度換取吞吐量。只適合「趨勢比每筆細節重要」的 metric 類事件。Error 和 lifecycle 事件不做聚合 — 每筆的 stack trace 和狀態轉換都有 debug 價值。

優先級丟棄

SDK 的離線 buffer 滿時，按優先級丟棄。Error 的 debug 價值最高，最後丟。

第二層：Collector 單機的防護

Collector 在自身能力範圍內保護自己不被壓垮。和 architecture.md 的並發寫入策略直接相關 — 寫入 channel 是背壓的實作基礎。背壓和流量管控的通用概念見 DevOps 流量管控。

寫入 channel 容量 + 背壓

Single-writer goroutine pattern 的 Go channel 有固定容量（如 10,000）。Channel 滿時 HTTP handler 無法送入事件，此時回 429：

1select {
2case writeCh <- event:
3    w.WriteHeader(http.StatusAccepted) // 202
4default:
5    w.Header().Set("Retry-After", "5")
6    w.WriteHeader(http.StatusTooManyRequests) // 429
7}

Channel 容量的設定依據：容量 × 每筆事件的記憶體大小 = 背壓 buffer 的記憶體上限。10,000 筆 × 每筆 ~1KB = ~10MB，對多數機器微不足道。

Per-SDK rate limiting

按 source.app（或 API key，啟用認證後）限制每個 SDK 實例的請求速率。防止單一 SDK 的 bug（無限迴圈送事件）打爆 collector。

1// 每個 source.app 一個 rate limiter
2limiter := rateLimiters.GetOrCreate(sourceApp, rate.Limit(100)) // 100 events/sec
3if !limiter.Allow() {
4    w.WriteHeader(http.StatusTooManyRequests)
5    return
6}

Error 快通道

Error 事件不經 rate limit — 它們的 debug 價值最高，且在正常情況下數量遠少於其他類型。Error storm（app 出 bug 導致大量 error）時，error 的量可能暴增，但這正是最需要記錄的時刻。

Error 快通道用獨立的 channel 或跳過 rate limiter 的 check。如果 error 量也超出承載，用第一層的 SDK 端優先級丟棄處理。

第三層：水平擴展

單機的 CPU、記憶體或網路頻寬飽和時，水平擴展 — 多個 collector 實例分攤流量。水平擴展的通用模式見 DevOps 水平擴展。

前提：已切換到 PostgreSQL

SQLite backend 不支援水平擴展。每個 collector 實例有各自的 SQLite 檔案，無法合併查詢。水平擴展的前提是所有 collector 寫入同一個 PostgreSQL。

架構

 1SDK ──→ Load Balancer (nginx / HAProxy)
 2             │
 3        ┌────┴────┐
 4        ▼         ▼
 5   Collector A  Collector B
 6        │         │
 7        └────┬────┘
 8             ▼
 9        PostgreSQL
10             │
11             ▼
12         Dashboard

Collector 實例是 stateless 的 — 不在記憶體保存查詢狀態，所有持久化資料在 PostgreSQL。任何 collector 接收的事件都能被任何 dashboard 查到。

Load balancer 用 round-robin 或 least-connections 分配。不需要 sticky session — collector 不保存 session 狀態。

多機的 Downsample 和 Purge

Downsample 和 Purge job 只能由一個 collector 實例執行（避免重複處理）。用 PostgreSQL 的 advisory lock 或外部的 distributed lock 確保單一執行者。

第四層：Queue 解耦

突發流量超過 collector 群的即時處理能力時，在 collector 和 storage 之間插入 message queue 做緩衝。Queue 緩衝的通用概念見 DevOps 突發流量應對，message queue 的選型見 Backend 模組三 非同步與訊息佇列。

架構

 1SDK ──→ Collector (ingestion only)
 2             │
 3             ▼
 4        Queue (Kafka / NATS / Redis Streams)
 5             │
 6        ┌────┴────┐
 7        ▼         ▼
 8    Worker A   Worker B
 9        │         │
10        └────┬────┘
11             ▼
12        PostgreSQL

Collector 的職責簡化為「接收 → 驗證 → 寫入 queue → 回 202」。寫入 queue 比寫入 DB 快得多（append-only、不需要索引更新），collector 的吞吐上限大幅提升。

Worker 從 queue 消費、寫入 PostgreSQL。Worker 按自己的速度處理 — 高峰時 queue 積壓，高峰過後 worker 消化積壓。Queue 的持久化保證事件不遺失。

Queue 的選擇

自架監控工具的 queue 層級推薦 NATS JetStream — Go 原生 client、單 binary 部署、JetStream 提供持久化和 replay。

觸發條件

Queue 解耦的引入時機是「collector 群已水平擴展但仍無法處理突發流量」。如果日常流量 collector 群能處理，只有行銷活動 / 新聞曝光的短暫高峰需要 queue 緩衝，queue 的維護成本可能高於收益 — 考慮用第一層的動態取樣在源頭降量。

功能分層整合

擴展 功能分層與 Backend 選擇 的分層表，加入 ingestion 維度：

每一層是前一層的超集 — Queue 層包含 PostgreSQL 層的所有查詢能力，加上 ingestion 的 queue 緩衝。

下一步路由

• Collector 的並發寫入策略 → Collector 架構
• Storage 端的擴展設計 → 規模演進
• 功能分層的定義 → 功能分層與 Backend 選擇
• 背壓和流量管控的通用概念 → DevOps 流量管控
• 水平擴展的通用模式 → DevOps 水平擴展
• 突發流量應對 → DevOps 突發流量
• Message queue 選型 → Backend 模組三 非同步與訊息佇列
• 端到端資料完整性（資料損失地圖、完整性指標）→ 端到端資料完整性

監控資料和交易資料的根本差異在這裡：交易資料的損失會直接造成商業損害（少了一筆訂單），監控資料的損失影響的是可觀測性的覆蓋率（少了幾筆 event 不影響趨勢判斷，但漏了 error 可能讓 bug 晚幾天被發現）。這個差異決定了完整性設計的方向 — 追求的是「損失可控且可觀測」，而非「零損失」。合規稽核 log、billing event 和安全事件不適用這個假設 — 它們的損失有法規或商業後果，需要 at-least-once delivery 和獨立的持久化保證，通常用 transaction log 而非監控管線處理。

資料損失地圖

一筆事件從產生到持久化，依序經過四個環節。每個環節的損失類型、發生條件和影響範圍各不同。

1事件產生 → [SDK buffer] → HTTP POST → [Collector pipeline] → [Storage]
2     ①          ②            ③              ④                   ⑤

環節一：事件產生階段

事件在 SDK 的 monitor.event() / monitor.error() 被呼叫時產生，進入記憶體 buffer。這個階段的損失來自取樣和 SDK 初始化時序。

靜態取樣：SDK config 中設定的取樣率（例如 metric 類 0.1 = 每 10 筆只收 1 筆）是設計內的損失。取樣後的事件量直接影響後續所有環節的負載。取樣率的設定依據見感測器生命週期管理。

SDK 未初始化：app 啟動後到 monitor.init() 完成之間的事件會被丟棄。如果 init 排在其他初始化邏輯之後，啟動階段的 crash 可能漏捕。商業 SDK（Sentry、Crashlytics）用 native crash handler 在 SDK 層之外攔截這類 crash，自架方案通常接受這個損失。

環節二：SDK buffer 階段

事件進入記憶體 buffer 後，等待 flush 觸發。Buffer 溢出和 app 強制終止是這段路徑上的兩個風險。

FIFO 丟棄：記憶體 buffer 有容量上限（典型值 200-500 筆）。離線時間過長或事件產生速率過高時，buffer 滿了會丟棄最舊的事件。丟棄策略見離線 buffer 與重試，優先級丟棄見 Ingestion Scaling 第一層。

App 強制終止：iOS 的 kill、Android 的 process death、Python 的 SIGKILL — 記憶體 buffer 中未 flush 的事件全部遺失。攢批送出策略的 close flush 嘗試在 app 正常退出時送出剩餘事件，但強制終止時連 close callback 都不會執行。

動態取樣：收到 collector 的 HTTP 429（Too Many Requests，表示 collector 過載）後，SDK 自動降低取樣率（從 1.0 降到 0.5 → 0.1）。這是對 collector 過載的回饋反應 — 損失的事件量隨背壓程度增加。和靜態取樣的差異是動態取樣在正常情況下不生效，只在過載時啟用。

環節三：Transport 階段

SDK flush 時透過 HTTP POST 送出 batch。網路故障和重試耗盡構成 transport 層的主要損失。

HTTP 超時 / 連線失敗：collector 不可達時，batch 保留在 SDK buffer 等待下次 flush 重試。重試次數有上限（3 次），超過後丟棄 batch 並記錄 sdk.flush.dropped metric。重試策略見攢批送出策略。

離線補發擁塞：離線恢復後，SDK 一次補發大量累積事件。如果補發速率過高（一批 500 筆 × 多個 SDK 同時恢復），collector 可能觸發背壓回 429，SDK 又進入動態降採樣 — 補發本身造成新的損失。離線 buffer 與重試的分批補發（每批 50-100 筆、間隔 1-2 秒）用來避免這個問題。

環節四：Collector pipeline 階段

Collector 收到 HTTP request 後，事件進入處理鏈路。背壓、驗證拒絕和 pipeline 內部的 buffer 溢出都可能在這裡造成損失。

Channel 背壓：Collector 內部用一個專屬的寫入 goroutine 搭配 Go channel 做序列化寫入（Collector 架構的並發寫入策略段），channel 有固定容量。Channel 滿時 HTTP handler 回 429，事件被拒絕。SDK 收到 429 後保留事件在 buffer 等待重試，但如果 SDK buffer 也快滿，部分事件會被 FIFO 丟棄。這裡的損失是 SDK 層和 collector 層的連鎖反應 — collector 的背壓壓力最終由 SDK 的 buffer 承擔。

Schema validation reject：事件格式不符合 JSON Schema 的事件被拒絕（400 或 207 中的 rejected 部分）。這是品質閘門而非容量限制 — 被拒絕的事件無論重試多少次都不會通過，SDK 應該清除這些事件並記錄 warning。問題在 SDK 端的事件建構邏輯（程式碼 bug），需要修 SDK 而非重試。

429 後事件已回 202 但未寫入：collector 回了 202（已接受）但事件還在 channel buffer 中未寫入 storage 時，如果 collector crash 或被 SIGKILL，channel 中的事件遺失。這是「已承諾但未持久化」的窗口。Container 部署設計的 graceful shutdown 序列嘗試在 shutdown 時 flush pending writes，但非 graceful shutdown（OOMKill、硬體故障）無法保護。

環節五：Storage 階段

事件從 channel 寫入 storage backend。寫入失敗和資料管理操作（downsample / purge）構成最後一段損失。

SQLite database is locked：busy timeout 到期後寫入失敗。Single-writer pattern 降低發生機率但不能完全消除 — downsample / purge job 執行期間持有 write lock，如果 job 跑太久（數秒以上），ingestion 的寫入可能逾時。

磁碟空間不足：SQLite 寫入需要磁碟空間（WAL 檔案 + 主資料庫 + 臨時檔案）。磁碟滿時寫入失敗，事件遺失。保留策略的 purge job 負責控制磁碟使用量，但如果 purge 頻率低於寫入增長速率，磁碟可能在兩次 purge 之間被填滿。

Downsample / purge 的設計內損失：保留策略到期的原始事件被刪除（purge），只保留聚合摘要（hourly_summary / daily_summary）。這是設計內的損失 — 原始事件的 stack trace、完整 JSON data 在 purge 後不可回復，只剩下計數。保留策略見規模演進的分層保留段。

設計內損失 vs 異常損失

上述損失點可以分成兩類，處理方式根本不同。

設計內損失的目標是讓損失量可控 — 取樣率設 0.1 代表預期丟 90%，FIFO buffer 容量 200 代表離線超過 20 分鐘（每分鐘 10 筆）後開始丟棄。這些數字是 config 參數，可以根據業務需求調整。

異常損失的目標是儘早偵測 — collector crash 後 channel 中有多少筆未寫入？磁碟使用率到多少該告警？下方的完整性指標段專門處理偵測異常損失的方法。

品質閘門的處理在 SDK 端而非 collector 端 — schema validation reject 的事件無論重試多少次都不會通過，問題在事件建構邏輯。具體的 reject 行為和回應格式見環節四的 Schema validation reject 段。

監控損失本身的方法

監控系統的完整性需要「監控自己的監控」— 用獨立的指標追蹤每個環節的進出量，損失量 = 進量 - 出量。

SDK 端指標

SDK 內部維護計數器，每次 flush 成功後一起送出（作為 metric 類事件）：

produced - sampled = 取樣損失（設計內）。sampled - sent - dropped 如果不為零，代表有事件卡在 buffer 中尚未送出或未被計入任何分類。

Collector 端指標

Collector 在 /metrics endpoint（或 health endpoint 的擴展欄位）暴露處理計數器：

received - rejected - stored - backpressure 如果不為零，代表有事件在 pipeline 中遺失（channel buffer 中的事件在 crash 時丟失就會造成這個差距）。

端到端比對

SDK 的 sent 和 collector 的 received 之間的差距是 transport 層的損失 — 網路丟包、中間件攔截（reverse proxy 的 body size limit）或 collector 重啟期間的連線失敗。

這個比對在自用場景下用手動 spot check 就夠（SDK log 的 sent count vs collector dashboard 的 received count）。小型以上規模需要自動化：一個定期 job 比對兩邊的計數器，差距超過閾值時告警。

損失率的可接受範圍

閾值的推導邏輯：event 類的損失影響統計精度 — 取樣率 0.9 加上 transport 和 collector 層的少量損失，自用場景合計 < 10% 是合理的上限；funnel 分析用取樣校正（除以取樣率）仍然有效。Error 類的損失直接影響 bug 發現速度 — 容忍度比 event 低一個數量級。中型以上規模的 < 1% / < 0.1% 接近商業方案（Sentry / Datadog）的 SLA 水準。

Ingestion Scaling 的 error 快通道設計就是基於這個優先級差異。

被自己的 SDK DDoS

「SDK 產生的流量壓垮自己的 collector」是自架監控系統最常見的可靠性事故。來源是自家 SDK 的異常行為或正常行為在特定條件下的放大效應 — 內部流量失控，而非外部攻擊。外部偽造流量的防護見 Client-side SDK 認證。

本段按觸發場景分類（SDK bug / 部署推送 / 使用者暴增），和 Ingestion Scaling 的四層防線（SDK 端 / collector 單機 / 水平擴展 / queue 解耦）是不同切面。四層防線按防護位置劃分、說明機制怎麼做；本段按場景劃分、說明什麼時候哪些機制會被觸發。

SDK bug：事件風暴

SDK 程式碼 bug 導致事件無限迴圈 — 常見於事件處理器內再次觸發事件（error handler 中呼叫 monitor.event() 又觸發 error），或 UI 事件綁定錯誤導致每個 frame 產生一筆事件（60 fps = 每秒 60 筆）。

損失路徑：事件風暴首先填滿 SDK buffer → 觸發高頻 flush → collector 收到大量 request → channel 滿觸發 429 → SDK 動態降採樣。如果 SDK 的動態降採樣邏輯本身也有 bug（降到 0.1 後不再降），collector 仍然會持續承壓。

防護層級：

SDK 端 — 事件產生速率上限。SDK 內部維護每秒事件計數器，超過閾值（例如 100 events/sec）後的事件直接丟棄，不進 buffer。這個上限獨立於取樣和背壓機制，是防止 SDK 自身 bug 的最後一道防線。

1// SDK 端的 rate limiter（偽碼，各語言實作不同）
2count = atomicIncrement(eventCounter)
3if count > maxEventsPerSecond:
4    atomicIncrement(droppedCounter)
5    return  // 不進 buffer

Collector 端 — per-key rate limit。每個 API key（或 source.app）的請求速率獨立限制。一個失控的 SDK 被限速時，其他 SDK 的事件不受影響。這和 Ingestion Scaling 的 per-SDK rate limiting 是同一個機制。

Collector 端 — circuit breaker。如果某個 API key 的 429 回應次數在短時間內超過閾值，collector 暫時拒絕該 key 的所有請求（回 503），不再逐筆檢查 rate limit。冷卻期過後自動恢復。這降低了 rate limit 本身的 CPU 開銷 — 高頻 429 回應也有成本。閾值需高於正常 burst 的 per-key 429 頻率 — 如果正常 flush 在 burst 時每分鐘最多觸發 N 次 429，circuit breaker 閾值設為 5N-10N 避免誤觸。具體數字（例如 50 次/分鐘、5 分鐘冷卻）依部署規模調整。

部署推送：補發風暴

100 台機器同時重啟（rolling deploy），每台機器的 SDK 在啟動時：

1. 讀取本地 persistence 中的離線事件
2. 初始化後立即 flush 離線事件 + 新的 lifecycle 事件

100 個 SDK 在幾秒內同時發起離線補發 + 正常 flush，collector 瞬間承受 100 倍的正常流量。

防護方式：init jitter — SDK 初始化後不立即 flush，而是等待一個隨機延遲（0 到 flush_interval 之間的均勻分佈）。100 個 SDK 的首次 flush 分散在 0-30 秒內，流量從一個尖峰變成斜坡。

1import random
2initial_delay = random.uniform(0, flush_interval_seconds)
3# 第一次 flush 延遲 initial_delay 秒，後續按正常 interval

離線補發也加 jitter — 每批補發之間的間隔從固定的 1 秒改為 1-3 秒的隨機值。100 個 SDK 的補發批次在時間軸上交錯，避免所有 SDK 以相同節奏同時送出。

使用者行為高峰：同時在線暴增

行銷活動、媒體報導、季節性高峰 — 同時在線使用者從 100 人暴增到 10,000 人。每個使用者的 SDK 正常運作，但總量超出 collector 的處理能力。

這個場景和 SDK bug 的差異：每個 SDK 的行為完全正常，問題在總量。Per-key rate limit 不會觸發（每個 SDK 的速率在正常範圍），需要的是全域流量控制。

防護方式：Collector 端的全域 channel 背壓（Ingestion Scaling 第二層）是第一道防線 — channel 滿時所有 SDK 收到 429，各自動態降採樣。如果動態降採樣後流量仍然過大，水平擴展（多 collector + load balancer）或 queue 解耦是解法。

行銷活動的可預測性是優勢 — 活動日期已知，可以提前擴展 collector 容量（加機器或調高 channel 容量）。突發的媒體報導則依賴動態降採樣和背壓的自動調節。

三種場景的防護對照

資料恢復 vs 接受損失

每個損失點都可以投入工程努力降低損失量。問題是恢復的工程成本是否值得 — 監控資料不是交易紀錄，恢復的價值取決於損失的事件類型和數量。

值得恢復的場景

Error 事件：每筆 error 都可能對應一個需要修的 bug。Error 的損失代表 bug 可能更晚被發現、在更多使用者身上發生後才被注意到。值得投入本地 persistence、優先級丟棄（error 最後丟）、error 快通道等機制降低損失。

Lifecycle 事件：session 邊界（session.begin / session.end）是 cohort 分析和 session replay 的基礎。丟失 session 邊界會讓整個 session 的事件無法正確歸屬。Lifecycle 事件量低（每 session 幾筆），保留成本小、損失影響大。

接受損失的場景

高頻 metric 事件：render.frame_time 每秒 60 筆，丟幾筆對趨勢分析的影響在統計誤差範圍內。聚合前移（SDK 端每 5 秒送一筆 summary）比逐筆保留更有效率。

行為 event 事件：button.click、page.view 在取樣後丟幾筆，funnel 的轉換率計算用取樣校正（除以取樣率）仍然有效。單筆行為事件的 debug 價值低 — 知道某使用者點了某按鈕通常不影響決策。

超過保留期的原始事件：purge 後只剩聚合摘要。如果分析需求發現需要更長的原始事件保留期，調整 retention config，不要嘗試從聚合摘要「恢復」原始事件 — 那是不可能的。

恢復成本的判斷

本地 persistence（SDK 端把 buffer 寫到檔案系統）的實作成本和收益：

MVP 階段用記憶體 FIFO。本地 persistence 作為第二階段功能，在離線損失率超出可接受範圍時投入。

下一步路由

• SDK 端的離線保護 → 離線 buffer 與重試
• Collector 端的流量防護 → Ingestion Scaling
• Collector 的處理鏈路 → Collector 架構
• Container 環境的 graceful shutdown → Container 部署設計
• 保留策略和降採樣 → 規模演進
• SDK 認證和偽造流量防護 → Client-side SDK 認證

概念位置

Backpressure 出現在 in-process channel、queue、worker pool、HTTP client、connection pool、broker 的 consumer 與 stream pipeline。它處理的是速度不匹配：進入速度高於處理速度。

Backpressure 與 rate limit 的差別在於資訊流向：rate limit 由上游主動設閘門（「每秒最多 N 個」），屬於容量規劃；backpressure 由下游回饋壓力（「我現在只能吃 M 個」），屬於動態調速。兩者常搭配使用：rate limit 處理已知的規劃容量，backpressure 處理無法預先預測的即時變化。

可觀察訊號

需要 backpressure 的訊號包含 queue depth 上升、記憶體持續增加、timeout 比例擴大、consumer lag 加深、下游 error rate 上升。當這些指標同時出現而上游流量維持穩定時，代表處理鏈某一段已成為瓶頸，壓力需要向上傳遞，而不是繼續往 buffer 堆積。

接近真實網路服務的例子

通知服務在行銷活動期間收到大量派送任務。若任務直接交給 worker 處理，worker 很快會塞滿下游第三方 API 的連線配額，latency 暴增、重試加倍，最終把佇列塞爆。導入 backpressure 後，服務依下游 API 實際吞吐動態調整 worker 取件速度：API 回應變慢時 worker 取件速度自動下降，上游請求端收到「任務已接收但延後送達」的回覆。整條 pipeline 的處理速度由最慢的一段決定，系統保留在可預測、可恢復的狀態。

設計責任

Backpressure 導入後，團隊需要定義以下邊界：buffer 大小、排隊上限、等待期限、拒絕策略、retry policy、load shedding 與對使用者的回饋（429 / 503 / 延後通知）。觀測上應能看到 queue depth、in-flight 數量、處理耗時、drop count、timeout、下游 error rate，並把關鍵指標放進 dashboard。

設計取捨的核心是 buffer 尺度：buffer 太小會讓瞬間尖峰被過度拒絕，流失可接受的請求；buffer 太大則延遲失控並可能拖累記憶體。穩定做法是「有限 buffer + 明確拒絕策略」，讓系統在超載時 fail fast，避免把壓力延後累積成更大的雪崩。

監控系統中 collector 用 HTTP 429 向 SDK 傳遞背壓的具體實作見 監控知識卡：Backpressure。