概念位置

Broker 把「送出訊息」與「處理訊息」分開。這個分離讓 request 可以先完成，背景工作可以稍後處理，也讓多個服務用同一個事件來源協作。RabbitMQ、Kafka、NATS JetStream、Redis Streams 都可以扮演 broker，但它們對 routing、持久化、順序、replay 與 consumer 協調的模型不同。

可觀察訊號

系統需要 broker 的訊號是工作已經超出單一 request 或單一 process 的生命週期。常見訊號包括寄信、轉檔、通知、同步外部系統、資料匯入、事件審計與跨服務廣播。這些工作需要排隊、retry policy、削峰或讓多個 consumer 分工處理。

接近真實網路服務的例子

電商付款完成後，訂單服務可以把 OrderPaid 事件交給 broker。寄信服務處理通知，倉儲服務處理出貨，分析服務處理報表。這些 consumer 的速度、失敗與部署週期彼此不同，broker 讓事件先被保存，再由各 consumer 依自己的節奏處理。

設計責任

Broker 導入後，系統要明確定義訊息格式、投遞保證、retry policy、dead-letter queue、consumer lag 告警、權限與 replay runbook。設計焦點是把「訊息送出去」升級成「訊息可追蹤、可恢復、可控制地被處理」。

概念位置

Consumer lag 是訊息系統的容量與健康訊號。Lag 上升代表某個 consumer group 正在累積未處理工作；lag 下降代表處理速度追上進入速度。不同 broker 的名稱不同，例如 Kafka 常看 offset lag，Redis Streams 可看 pending 與未讀項目，RabbitMQ 常看 queue depth 與 unacked messages。 可先對照 Consumer。

可觀察訊號

系統需要關注 consumer lag 的訊號是「工作延遲開始影響產品結果」。例如通知延遲、報表延遲、搜尋索引更新延遲、訂單狀態同步延遲。Lag 也常伴隨 CPU 飽和、下游 API 變慢、資料庫鎖競爭或 consumer 反覆重試。

接近真實網路服務的例子

外送平台在尖峰時段大量產生訂單事件。若地圖更新 consumer 的 lag 持續上升，使用者看到的騎手位置會落後；若付款入帳 consumer 的 lag 上升，客服與帳務對帳會延後。兩者都叫 lag，但產品代價不同，因此告警門檻也應分開設計。

設計責任

Consumer lag 要搭配 runbook 使用。Runbook 應說明 lag 上升時先看進入量、處理耗時、錯誤率、下游延遲、重試數與 instance 數量；再決定擴容、暫停低優先工作、修復 poison message 或調整下游保護。

概念位置

Dead-letter queue 是可靠性與診斷工具。它讓系統把暫時性失敗與需要人工判斷的訊息分開：暫時性失敗可以重試，需要分析的訊息則進入隔離區，等待修復資料、修復程式或建立 replay runbook。

可觀察訊號

系統需要 dead-letter queue 的訊號是某些訊息反覆阻塞處理流程。常見原因包括 payload schema 與 consumer 版本不同步、外部系統回傳永久錯誤、資料狀態已被取消、權限不足或訊息內容缺少必要欄位。

接近真實網路服務的例子

訂單通知 consumer 連續處理某筆事件失敗。訊息留在主要 queue 反覆重試時，後續正常訂單可能延遲；訊息進入 dead-letter queue 後，on-call 可以查看失敗原因、修復資料或部署修正後再重放該批訊息。

設計責任

Dead-letter queue 要搭配分類欄位與處理流程。訊息進入隔離區時，應保留錯誤類型、最後錯誤、重試次數、原始 topic、correlation id 與建立時間；runbook 應定義誰能重放、重放前檢查什麼、如何控制副作用範圍。

概念位置

Replay 常用在修復資料、補送事件、重建投影、重新產生搜尋索引或處理 dead-letter queue。它是一種高權限操作，因為同一批事件再次執行可能觸發通知、扣款、出貨、積分或外部 API 呼叫。

可觀察訊號

系統需要 replay runbook 的訊號是「資料可以由事件重建，但重建會影響現有狀態」。例如報表漏算一段時間、搜尋索引落後、某版 consumer 寫錯衍生資料、dead-letter queue 累積一批已修復訊息。這些情境都需要重放，但每種重放的副作用不同。

接近真實網路服務的例子

會員等級計算服務因部署錯誤漏掉一天事件。團隊可以從 event log 重放該日事件重建會員等級；runbook 需要指定時間範圍、只重建等級投影、暫停對外通知，並在重放後比對抽樣帳號與總量指標。

設計責任

Replay runbook 應包含 dry run、資料備份、權限核准、rate limit、觀測 dashboard 與停止條件。設計重點是讓重放成為可審核、可停止、可驗證的操作，而非臨時手動補資料。

概念位置

重複投遞是可靠訊息系統的正常設計條件。它要求 consumer 把「收到訊息」與「造成外部結果」分開思考，並用 idempotency key、dedup store、唯一約束、狀態機或業務檢查讓多次處理得到同一個結果。 可先對照 Durable Queue。

可觀察訊號

系統需要處理重複投遞的訊號是訊息會造成金錢、庫存、通知、帳務、點數或外部 API 副作用。只更新可重建投影的事件，重複通常只增加成本；會寄信、扣款、出貨或新增記錄的事件，重複可能造成產品事故。

接近真實網路服務的例子

付款成功事件被投遞兩次。若出貨 consumer 只看「收到付款事件」就建立出貨單，可能造成重複出貨；若 consumer 以付款交易 ID 建立唯一處理紀錄，第二次投遞會命中已處理狀態，結果保持穩定。

設計責任

Consumer 設計要明確標出 idempotency 邊界。重要事件應有穩定事件 ID、業務鍵、處理紀錄與可觀測欄位；測試要包含同一訊息連續處理、處理中 crash 後重試、外部 API timeout 後重試等情境。

概念位置

快取失效是讀取效能與資料正確性的交界。失效太頻繁會降低快取命中率；失效太慢會讓使用者看到過期資料。多層快取還會增加判斷難度，因為 browser、CDN、application cache、Redis 與 local memory 可能各自保存不同版本。 可先對照 Cache Prefetching。

可觀察訊號

系統需要整理失效策略的訊號是資料更新後，讀取結果在不同頁面、不同使用者或不同服務之間出現差異。常見場景包括商品價格、庫存、會員權限、設定檔、排行榜、熱門文章與 feature flag。

接近真實網路服務的例子

電商後台更新商品價格後，搜尋頁仍顯示舊價格，商品頁顯示新價格，結帳頁又重新查資料庫。這代表不同讀取路徑使用不同快取層，失效策略需要定義更新事件要清哪些 key、哪些頁面可接受短暫延遲、結帳是否必須讀正式來源。

設計責任

快取設計要把資料語意分級。價格、庫存、權限這類影響交易或安全的資料需要更短 TTL、版本控制或讀正式來源；排行榜、推薦與統計可以接受較長延遲。Runbook 應提供查 key、清 key、比對正式資料與追蹤失效事件的方法。

概念位置

資料不一致需要先分辨 source of truth 與衍生資料。Source of truth 承擔正式判斷，例如訂單付款狀態；衍生資料負責查詢、展示或分析，例如搜尋索引與報表。設計時要明確哪些資料可以重建，哪些資料代表正式狀態。 可先對照 Data Lifecycle。

可觀察訊號

系統需要處理資料不一致的訊號是不同入口看到不同結果。使用者頁面、客服後台、管理報表、搜尋頁、通知訊息與第三方系統若對同一筆資料有不同說法，團隊就需要追蹤資料從正式來源到各副本的傳播路徑。

接近真實網路服務的例子

使用者取消訂單後，訂單詳情顯示已取消，但搜尋列表仍顯示可出貨。若出貨流程讀搜尋索引，可能產生錯誤操作；若出貨流程讀正式訂單資料，搜尋列表延遲只影響展示。這個差異決定修復優先級。

設計責任

資料不一致的 runbook 要能回答四件事：正式來源在哪裡、哪些副本落後、更新事件是否送達、是否需要補償或重建。系統也要提供版本、更新時間、correlation id 或事件 ID，讓排查能沿著資料流定位。

概念位置

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

可觀察訊號

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

接近真實網路服務的例子

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

設計責任

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

概念位置

停機討論要回到產品承諾。不同服務的中斷代價不同：登入停機會阻止使用者進入系統，付款停機會直接影響收入，報表停機可能延後內部決策，通知停機可能造成延遲但可補送。 可先對照 Draining。

可觀察訊號

系統需要停機應變設計的訊號是服務有明確 SLO、收入影響、法規要求、資料保存責任或大量使用者依賴。停機風險也會在部署頻繁、單點依賴、缺少備份、缺少演練或缺少 rollback 時上升。

接近真實網路服務的例子

票券平台開賣時付款服務停機。系統需要先保護訂單狀態與付款一致性，再決定是否暫停結帳、排隊等候、延長付款期限或開啟公告。若只追求快速恢復流量，可能讓使用者重複付款或訂單狀態混亂。

設計責任

停機 runbook 要定義事件分級、對外溝通、負責人、rollback、備援切換、資料保護與事後復盤。關鍵系統還要預先定義 RTO、RPO、備份驗證、演練頻率與決策權限。

概念位置

Readiness 是 application 與平台之間的流量合約。Application 啟動成功只代表 process 存活；readiness 代表必要設定、連線、migration 狀態、背景初始化、cache warmup 或依賴檢查已達到接流量條件。 可先對照 Redelivery Loop。

可觀察訊號

系統需要 readiness 合約的訊號是部署或擴容期間出現短暫錯誤。常見情境包括 pod 剛啟動就接流量、service discovery 尚未更新、cache 還在 warming、資料庫連線池尚未建立、背景 worker 尚未完成初始化。

接近真實網路服務的例子

Kubernetes rolling update 建立新 pod 後，若 readiness 太早通過，新 pod 可能在還沒載入設定時接到 checkout request。正確的 readiness 會等必要依賴可用、設定載入完成、核心路由可處理後再開放流量。

設計責任

Readiness endpoint 要反映接流量所需的最小條件，並且控制下游短暫波動對流量調度的影響。設計時要分清 readiness、liveness 與深度依賴檢查，讓平台能做穩定調度。

概念位置

Graceful shutdown 是 application 與部署平台的停止合約。平台負責送出停止訊號、移出流量與設定期限；application 負責停止入口、排空處理中工作、釋放連線、提交 checkpoint、送出最後 log 與 metrics。 可先對照 Draining。

可觀察訊號

系統需要 graceful shutdown 的訊號是部署、擴容縮容或主機維護時出現 request 中斷、訊息重複、長連線突斷、資料寫入半途失敗或 worker 遺失進度。這些現象表示停止流程與工作生命週期沒有對齊。

接近真實網路服務的例子

背景 worker 正在處理影片轉檔時收到部署停止訊號。Graceful shutdown 應停止取得新工作，讓目前轉檔在期限內完成；若超過期限，worker 需要保存進度或讓 broker 重新投遞，並留下可追蹤的狀態。

設計責任

Graceful shutdown 要搭配 timeout、draining、idle timeout、idempotency 與觀測訊號。Runbook 應能看到停止期間的 in-flight request、consumer ack、長連線數、錯誤率與強制終止次數，讓部署問題可以被定位。

概念位置

Source of truth 讓系統知道衝突時該相信誰。訂單狀態通常以訂單 database 為準，搜尋索引只是查詢副本；會員權限通常以權限服務或 database 為準，快取只是加速讀取。 可先對照 Database。

可觀察訊號與例子

系統需要明確 source of truth 的訊號是不同入口呈現不同結果。客服後台顯示訂單已取消，搜尋頁仍顯示可出貨時，團隊要先知道出貨流程應讀正式訂單資料，而非搜尋索引。

設計責任

資料設計要標出正式來源、衍生副本、重建方式與修復順序。Runbook 應說明資料衝突時如何查正式來源、如何重建副本、如何確認修復完成。

概念位置

資料生命週期連接產品需求、成本與資安。訂單資料可能需要長期保存以支援稽核；debug log 可能只保留數天；匯出檔案可能需要短期下載期限與自動清除。 可先對照 Data Masking。

可觀察訊號與例子

系統需要資料生命週期設計的訊號是資料量持續成長、使用者要求刪除資料、稽核要求保存證據，或觀測資料成本快速上升。聊天訊息、付款紀錄、trace、報表檔案的保留策略通常不同。

設計責任

生命週期設計要定義保留期限、刪除流程、封存策略、備份影響、權限與 audit。資料移除時也要處理 cache、search index、object storage、log 與第三方系統副本。

概念位置

交易適合保護同一個 database 內的正式狀態變更。建立訂單與扣庫存可能需要同一個交易；寄信、呼叫外部 API 或發布 broker 訊息則常需要 outbox pattern 或補償流程，因為它們超出 database transaction 能力。

可觀察訊號與例子

系統需要交易邊界的訊號是「半成功」會造成產品錯誤。若付款紀錄已建立但訂單狀態未更新，客服與帳務會看到衝突狀態；若通知寄送失敗，通常可以重試或補送。

設計責任

交易邊界要盡量短，並明確處理 deadlock、retry policy、timeout 與錯誤分類。跨 database 或跨服務的一致性要改用 outbox、saga、補償或 data reconciliation，而非假設單一交易能包住所有事情。

概念位置

Migration 是 database 與 release 流程的交界。小型服務可能只需要簡單版本檔；正式服務通常需要 Expand / Contract 策略，先新增可相容欄位，再部署 application，最後移除舊欄位。

可觀察訊號與例子

系統需要 migration 策略的訊號是多個版本會同時存在。Rolling update 期間，新舊 application 可能同時讀寫資料庫；若 migration 一次移除舊欄位，舊版本 instance 可能立刻失敗。

設計責任

Migration 設計要包含相容性、backfill、索引建立成本、鎖表風險、回滾策略與 Release Gate。高風險 migration 應先在接近正式資料量的環境驗證。

概念位置

隔離級別處理的是同一份資料被多個交易同時讀寫時的行為。常見問題包括 dirty read、non-repeatable read、phantom read、lost update 與 write skew。不同資料庫的預設隔離與實作細節不同。 可先對照 Jitter。

可觀察訊號與例子

系統需要討論隔離級別的訊號是高併發更新同一類資料。兩個使用者同時搶最後一件庫存、兩個 worker 同時認領同一筆工作、兩個後台操作同時修改權限，都需要明確的一致性策略。

設計責任

設計時要先定義可接受的並發結果，再選擇 transaction、lock、unique constraint、optimistic concurrency 或 retry。隔離級別是工具之一，業務層仍需要狀態機與唯一約束表達正式規則。

概念位置

連線池是 application 並發與下游容量的閘門。Pool 太小會讓 request 等待；pool 太大會把壓力轉移到資料庫或外部服務，造成 timeout、排隊與資源耗盡。 可先對照 Consumer Capacity。

可觀察訊號與例子

系統需要檢查 connection pool 的訊號是 latency 升高但 CPU 不高，或高峰時大量 request 等待資料庫。活動期間 checkout 變慢，可能是 database pool 已滿，也可能是資料庫本身查詢變慢。

設計責任

Pool 設定要搭配 timeout、查詢耗時、instance 數量與下游最大連線數。Runbook 應能看到 pool in-use、idle、wait count、timeout 與下游 error rate。

概念位置

TTL 是資料新鮮度與操作成本的取捨。TTL 長可以提高命中率與降低下游壓力；TTL 短可以降低過期資料風險，但會增加重新載入與下游查詢。 可先對照 Unacked Message。

可觀察訊號與例子

系統需要調整 TTL 的訊號是資料過期造成錯誤體驗，或 cache miss 造成下游壓力。商品價格 cache 的 TTL 通常短於熱門文章榜；presence 狀態需要跟心跳頻率一起設計。

設計責任

TTL 要依資料語意分級，並搭配主動失效、版本鍵或背景刷新。Runbook 應能查 key 剩餘時間、命中率、miss rate 與過期後重建成本。

概念位置

Eviction 處理的是容量控制，TTL 處理的是時間有效性。Redis、CDN、local cache 都可能在容量壓力下淘汰資料；被淘汰的資料若可重建，系統會承擔額外查詢成本。 可先對照 Excessive Data Exposure。

可觀察訊號與例子

系統需要關注 eviction 的訊號是 cache hit rate 突然下降、Redis memory 接近上限、下游資料庫壓力升高。熱門商品活動可能讓大量 key 進入快取，造成原本常用資料被擠出。

設計責任

Eviction 策略要搭配 key 設計、容量規劃、資料重要性與告警。高價值或難重建資料應有更穩定的保存方式，一般快取淘汰策略只適合可重建資料。

概念位置

Cache aside 適合可重建的讀取資料。商品詳情、權限摘要、設定檔與熱門內容常用這種方式加速讀取；正式資料仍然在資料庫或下游服務，快取只是副本。 可先對照 Cache Hit / Miss。

可觀察訊號與例子

系統適合 cache aside 的訊號是讀多寫少、資料可重建、讀取成本高。商品頁查詢頻繁時，cache aside 可以降低資料庫壓力；結帳確認價格時仍應回到正式來源或使用更嚴格一致性策略。

設計責任

Cache aside 要定義 cache miss、資料載入、寫回、失效、錯誤 fallback 與防止 stampede 的方式。測試要覆蓋 hit、miss、正式來源失敗、快取寫入失敗與過期資料情境。

概念位置

Hot key 是流量分布問題。總 QPS 看起來可承受時，單一商品、直播間、明星帳號、熱門活動或全域 counter 仍可能把某個 shard、partition 或 Redis node 打滿。 可先對照 HTTP Client。

可觀察訊號與例子

系統需要 hot key 分析的訊號是整體容量尚可，但特定頁面、特定商品或特定 tenant 延遲異常。大型促銷活動中，熱門商品庫存 key 可能比其他商品多出數百倍讀寫。

設計責任

Hot key 設計要考慮分片、local cache、讀寫分離、批次更新、限流與降級。觀測上要能按 key pattern、tenant、topic 或 partition 看流量集中度。

概念位置

Cache stampede 是快取失效與下游保護的交界。快取原本用來保護資料庫；若熱門資料同時過期，快取反而會把大量請求集中送到資料庫。 可先對照 Cache Warmup。

可觀察訊號與例子

系統需要處理 stampede 的訊號是 cache miss rate 突然升高，同時資料庫查詢數、latency 與 timeout 上升。熱門文章榜每分鐘整點過期，可能讓所有 request 在同一秒重建同一份資料。

設計責任

常見策略包括 singleflight、soft TTL、background refresh、jitter、lock 與 fallback stale data。設計時要讓少數 request 負責重建，多數 request 使用既有資料或等待有界時間。

概念位置

Ack / nack 是投遞保證的關鍵協議。Consumer crash、網路中斷或 ack timeout 都可能讓 broker 判斷訊息尚未完成，進而 redelivery。

可觀察訊號與例子

系統需要理解 ack / nack 的訊號是訊息重複、queue depth 上升或 unacked message 累積。影片轉檔 worker 若在完成前 crash，訊息應重新投遞；若已產生外部副作用，consumer 需要 idempotency 保護。

設計責任

Consumer 要明確決定何時 ack。通常應在業務處理與必要狀態保存完成後 ack；永久性錯誤要分類送往 dead-letter queue；暫時性錯誤要搭配 retry policy、exponential backoff 與 jitter。

概念位置

Retry policy 跟 dead-letter queue 構成錯誤處理的兩層機制 — retry 處理暫時性失敗，DLQ 承接 retry 耗盡後仍無法處理的訊息。Retry 跟 idempotency 是成對的設計 — 有 retry 就要有 idempotent consumer，否則重試可能造成重複扣款、重複發通知。

Retry 跟 retry storm 的關係是：大量 consumer 同時 retry 失敗的訊息會形成下游的流量尖峰，把暫時性故障放大成全系統問題。Exponential backoff + jitter 是緩解 retry storm 的標準做法。

使用情境

系統需要 retry policy 的訊號是下游偶發失敗影響成功率。付款查詢 API 短暫 timeout 可以重試；已送出的扣款請求則需要先查詢結果或用 idempotency key，避免重試造成重複扣款。

Retry 的判斷分類：暫時性錯誤（5xx、timeout、connection refused）適合 retry；永久性錯誤（4xx、schema validation failure、business rule violation）不應該 retry，直接送 DLQ 或 reject。分類錯誤是 retry policy 最常見的 bug — 對永久性錯誤 retry 只會消耗 quota、延遲問題被發現的時間。

設計責任

Retry policy 要包含最大重試次數、backoff 策略（fixed / exponential / exponential + jitter）、每次 retry 的 timeout、錯誤分類規則（哪些 error code 算暫時性）、觀測欄位（retry count、最終結果）與停止條件（超過 N 次進 DLQ）。高流量系統還要設定 retry budget — 限制 retry 流量佔總流量的比例，避免 retry 自身成為負載來源。

概念位置

Idempotency 是副作用邊界的穩定性設計。查詢通常天然接近 idempotent；建立訂單、扣款、出貨、寄送通知與發放點數都需要額外設計 idempotency key 或狀態檢查。 可先對照 Idle Timeout。

可觀察訊號與例子

系統需要 idempotency 的訊號是同一 intent 可能重送。使用者按兩次付款、broker 重複投遞付款成功事件、HTTP client timeout 後重試，都可能讓同一業務意圖進入系統多次。

設計責任

Idempotency 設計要有穩定 key、唯一約束、處理紀錄、結果查詢與過期策略。測試要覆蓋連續重送、處理中 crash、外部 API timeout 與 replay。

概念位置

Outbox 解決的是資料已寫入但事件發布失敗的半成功問題。資料庫交易保護業務狀態與 outbox 紀錄；broker 發布則用後續重試與 idempotency 保證最終送出。 可先對照 Ownership。

可觀察訊號與例子

系統需要 outbox 的訊號是「狀態改變後，其他服務必須知道」。訂單付款完成後，倉儲、通知與分析都需要收到事件；若事件發布失敗但訂單已付款，後續流程會漏執行。

設計責任

Outbox 要設計 event schema、publisher checkpoint、retry、dead-letter、去重與監控。Runbook 應能看到 outbox backlog、發布錯誤、最舊未發布時間與 replay 流程。

概念位置

Saga 處於跨服務分散事務的設計層。Saga 解「跨服務事務一致」、outbox 解「事件不丟」、idempotency 解「補償可重放」。兩種常見實作 variant：

• Choreography（編舞）：每個服務監聽事件、自行決定下一步動作、不需要中央協調者。耦合低；業務流程散落、debug 困難。
• Orchestration（編排）：用一個中央 saga orchestrator 持有 state machine、逐步呼叫各服務並追蹤狀態。流程集中可見；orchestrator 是單點。

可觀察訊號與例子

電商 checkout 是典型 saga：下訂單 → 扣庫存 → 扣餘額 → 出貨。任一 step 失敗、反向觸發補償（退款、回滾庫存、取消訂單）。Order management、支付清算、跨服務交易都會用到。補償 transaction 失敗率非零、saga 引擎需要 retry + dead letter queue 處理。

設計責任

補償 transaction 必須是 idempotent — saga 引擎在故障重試時會重放補償。缺 idempotent 設計時、saga 補償會變成新事故來源。Choreography vs orchestration 的選擇要看「業務流程穩定度」— 流程穩定可走 choreography 簡化耦合、流程多變或 audit 要求高選 orchestration 保留 state machine。Saga timeout 跟 step timeout 要明示、確保 saga 推進到終態（成功或補償完成）。

概念位置

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。

概念位置

Consensus protocol 處於分散式系統的協調控制底層、上面分別構築 leader election、state machine replication、cluster membership 三類能力。每筆 write 通常要跨 majority quorum 節點 round trip — 5 節點 cluster 失去 3 節點以上就停寫保護（防範 split-brain）。對比 gossip protocol（SWIM、Serf）— consensus 給「強一致順序」、gossip 給「最終一致成員管理」、各自適用情境。

可觀察訊號與例子

Etcd / Consul / ZooKeeper 都是 consensus 服務、被 Kubernetes、Vault、Patroni 等系統當 coordination backend。實測 commit latency 隨 cluster 大小升高（3 節點同 AZ ~ 1-5ms、5 節點跨 region 可能 50-200ms）。故障恢復期間 election timeout 典型 150-500ms、期間短暫不可寫。CockroachDB / Spanner 在 OLTP write 路徑同樣依賴 consensus、是寫入延遲的下限。

設計責任

水平擴展 stateful 服務時、若依賴 distributed lock 或 leader election 來協調工作、要把 consensus latency 算進事故時的 RTO。Quorum 大小設計要考慮「容忍 N 節點失效」需要至少 2N+1 節點。跨 region 部署的 consensus 服務、要明示「region 失效時降級為 read-only」的策略 — region 失效時 quorum 可能跨不過、要事先規劃降級路徑。

概念位置

Rate limit 是容量保護與公平性工具。它可以保護登入、搜尋、匯出、第三方 API、webhook endpoint 與下游服務，降低單一來源耗盡共享資源的風險。 可先對照 Producer。

可觀察訊號與例子

系統需要 rate limit 的訊號是少數使用者或客戶端造成大量 request。匯出報表 API 缺少 rate limit 時，單一 tenant 的批次工作可能佔滿 database connection pool，影響其他 tenant 的正常查詢。

設計責任

限流設計要定義主體、窗口、配額、超限回應、例外權限與觀測欄位。對外 API 要提供清楚的 retry-after 或配額資訊；內部服務要搭配 alert、token bucket 與容量規劃。完整的實作指南（單機 middleware、Redis 分散式限速、配額設計）見 Rate Limit 實作。

監控系統中 per-SDK rate limiting 和偽造流量防護的具體實作見 監控知識卡：Rate Limiting。

概念位置

SWR 處於 HTTP cache 失效策略層、跟 TTL、Cache Invalidation 是兄弟概念。TTL 定義「何時 expire」、SWR 定義「expire 之後仍允許用舊版的時間窗口」、cache invalidation 定義「主動清掉」。跟 Stale-If-Error 屬不同維度但常一起配置 — SWR 處理過期、SIE 處理錯誤。

可觀察訊號與例子

Cache-Control: max-age=60, stale-while-revalidate=600 的服務行為：60 秒內 cache 完全新鮮、60-660 秒之間 client 仍立即拿到舊版（但 cache 已背景重整）、660 秒後才強制等 origin response。Cloudflare / Fastly / Varnish 都支援、瀏覽器 cache 也尊重這個 directive。

新鮮度敏感的場景（庫存、價格、權限）應限縮 SWR 範圍或關閉、保住 stale 風險的上限；blog 文章、商品描述、靜態 metadata 適合 SWR 降低 origin 壓力。

設計責任

選擇 SWR window 要在「origin 壓力」跟「freshness budget」間取捨。Window 越長、origin 壓力越低、stale 容忍度越高；window 越短、freshness 越接近 TTL、但 cache stampede 緩解效果下降。常見組合是 stale-while-revalidate 設成 max-age 的 5-10 倍。資料新鮮度敏感場景要走白名單路徑、由 endpoint 個別 opt-in 開啟 SWR。

概念位置

Circuit breaker 是失敗隔離工具。它通常搭配 timeout、retry policy、rate limit、fallback 與 dashboard 使用；目標是控制故障擴散，而非修復下游。

可觀察訊號與例子

系統需要 circuit breaker 的訊號是下游錯誤率高、latency 飆升，並拖慢上游服務。推薦服務持續 timeout 時，商品頁可以短暫停止呼叫推薦，改顯示熱門商品。

設計責任

Circuit breaker 要定義開啟條件、半開探測、恢復條件、fallback 行為與 alert。設計時要控制短暫波動對可用性的影響，因此門檻與 metrics 要一起調整。

概念位置

SIE 處於 HTTP cache 失效策略層、是 cache 從「降延遲工具」升級成「fallback 機制」的關鍵 directive。跟 TTL、Cache Invalidation 是兄弟。觸發條件跟 SWR 不同：SWR 是「TTL 過期但 origin 正常」、SIE 是「origin 出錯」— 一個是 condition-driven、一個是 error-driven。

可觀察訊號與例子

Cache-Control: max-age=60, stale-if-error=86400 的服務行為：origin 正常時、60 秒新鮮、之後正常 revalidate；origin 回 5xx 或網路不可達時、cache 在 86400 秒（1 天）內仍可用舊版本回應。Cloudflare / Fastly / Akamai 支援度因 vendor 而異、部分 vendor 有 origin shield 整合。

電商商品頁、新聞文章、blog post 適合大 SIE window（origin 出事時舊版可用 1-7 天）；交易型 API、付款流程應該關閉 SIE — 在這類場景中、回 5xx 讓 client retry 比回 stale 安全。

設計責任

開啟 SIE 是明示「在 origin 故障期間、業務願意接受 stale data 換 availability」。Freshness-sensitive 場景要走白名單路徑、由 endpoint 個別 opt-in 開啟 SIE。SIE window 通常比 SWR 長（後者是常態、前者是故障 fallback）— 常見組合是 SIE 設一天、SWR 設十分鐘。同時搭配 origin 監控、確保 SIE 期間真實事故仍被察覺。

概念位置

Failover 是可用性設計的一部分。它要處理健康判斷、切換觸發、資料一致性、DNS 或 load balancer 更新、連線重建與回切流程。 可先對照 Fallback Plan。

可觀察訊號與例子

系統需要 failover 的訊號是單一節點、單一區域或單一供應商故障會造成停機。付款服務可以在主要供應商中斷時切到備援供應商，但要處理交易查詢、費率、風控與對帳差異。

設計責任

Failover runbook 要定義觸發條件、切換步驟、資料檢查、回切條件與演練頻率。自動 failover 需要更嚴格的健康訊號，人工 failover 則需要清楚的決策權限。

概念位置

Leader election 處於分散式協調控制層、是 consensus protocol 三大責任（election / state machine replication / cluster membership）中最常被獨立使用的一支。常見實作載體：ZooKeeper ephemeral node、Etcd lease + revision、Consul session、Kubernetes lease object、Redis 加 fencing token 的近似實作。

可觀察訊號與例子

每個 cluster 同時間至多一個 leader 持有 election lease；leader 失效後典型 election timeout 在 150ms-500ms 之間（依 consensus 算法跟 cluster 大小）。應用情境包含：分散式排程器（Quartz cluster、Apache Airflow scheduler）、Kafka controller、PostgreSQL primary 選舉（Patroni）、Kubernetes controller manager / scheduler 的 leader-elect 機制。

設計責任

Election timeout 太短會誤判（網路抖動觸發多餘的切換）、太長會延遲 failover。Fencing token 是必備設計 — 舊 leader 跟新 leader 並存的 split-brain 期間、用單調遞增 token 讓資源側拒絕舊 leader 的寫入。應用層接 leader election 要明確「在 follower 角色時做什麼」— 通常是 stand-by + 監控 election event、每個操作前主動檢查自己當前是否為 leader。

概念位置

Liveness 關注 process 是否卡死、主 loop 是否停止、必要 runtime 是否失效。Readiness 關注接流量條件。兩者混用會讓平台在下游短暫故障時重啟正常 instance，造成更大波動。 可先對照 Health Check。

可觀察訊號與例子

系統需要分清 liveness 與 readiness 的訊號是部署或下游波動時 instance 被反覆重啟。資料庫短暫 timeout 應影響 readiness 或功能降級；process deadlock 才應觸發 liveness 失敗。

設計責任

Liveness check 要簡單、穩定、成本低。Runbook 應說明 liveness fail 代表什麼、平台何時重啟、重啟後如何觀察 crash loop 與資源限制。

概念位置

Log schema 是可觀測性的事件明細層。Metrics 提供趨勢，trace 提供跨服務路徑，log 提供單一事件的上下文與細節。三者透過共享欄位（trace id、correlation id）互相連結。

Log schema 的穩定性決定了查詢的效率 — 跨服務使用不同的欄位名稱記錄同一概念時，查詢需要窮舉所有變體。見 4.1 log schema 與搜尋規劃。

使用情境

系統需要 log schema 的訊號是事故時查詢依賴全文搜尋或逐台機器翻查。Checkout 失敗時，穩定欄位讓團隊用 order_id、payment_id、request_id 在秒級內追出同一流程的所有紀錄。

設計責任

Log schema 要控制欄位名稱（跨服務統一）、錯誤分類（error type / error code 有界而非 free-form message）、敏感資料遮罩（API key / token / PII 在寫入前 redact）與索引成本（高 cardinality 欄位不全部建索引）。高流量服務還要管理 log level、sampling、retention 與查詢成本。

概念位置

Metrics 是趨勢觀測跟 alert 的基礎。跟 log（事件明細）跟 trace（跨服務路徑）互補：log 適合查單一事件的細節，trace 適合看一次 request 的路徑，metrics 適合回答「服務是否在變慢、錯誤是否在增加、容量是否接近上限」。

Metrics 有三種基本型別：counter（累積計數、只增不減）、gauge（瞬間值、可增可減）、histogram（分布、支援 percentile 計算）。選錯型別會讓後面的 SLI、dashboard 跟 alert 建立在錯誤訊號上。

使用情境

系統需要 metrics 的訊號是團隊需要在使用者回報前知道服務異常。Checkout p95 latency 上升、Redis timeout 增加、broker lag 擴大，都應先從 metrics 看見。

設計責任

Metrics 設計要選擇正確的型別（latency 用 histogram、request count 用 counter、connection pool size 用 gauge）跟有界的 label（service、method、status_code，排除 user_id / request_id）。重要指標要能對應 SLI / SLO 跟 runbook；高 cardinality label 會推高儲存跟查詢成本。Metrics 的聚合查詢跟 recording rule 設計見 4.2 metrics basics。

概念位置

SLI / SLO 把觀測資料轉成決策語言。單純看到 error rate 上升只能說明症狀；對照 SLO 後，團隊才能判斷是否需要暫停發版、啟動 incident、擴容或降級。SLO 不是「越高越好」— 99.999% 的 SLO 意味著幾乎沒有 error budget 做變更，反而限制了功能交付速度。

SLI 的設計起點是使用者旅程（checkout 是否成功、搜尋是否夠快），量測點選擇（edge / gateway / service）決定了 SLI 反映的是「使用者體驗」還是「基礎設施健康」。

使用情境

系統需要 SLI / SLO 的訊號是服務重要性已經影響收入、合約或使用者信任。付款、登入、訂單建立與訊息送達通常需要不同 SLO，因為失敗代價不同。

設計責任

SLI 需要定義「什麼算 good request」的邊界（5xx 算 bad、4xx 通常不算）。SLO 需要定義目標值、量測窗口（30 天 rolling）跟 owner。SLO 跟 burn rate alerting 搭配使用，讓 alert 反映使用者影響而非基礎設施噪音。完整設計見 4.6 SLI/SLO 訊號設計。

概念位置

Trace context 是跨服務診斷的關聯層，跟 correlation id 互補 — correlation id 關聯業務流程、trace context 關聯技術呼叫路徑。它的傳遞機制決定 trace 能不能完整串起 — context 斷掉的地方，trace 就從「完整路徑」退化成需要人工拼接的局部紀錄。

W3C Trace Context 標準定義了 HTTP 的傳遞格式：traceparent header 帶 version + trace id + parent span id + trace flags，tracestate header 帶 vendor-specific 附加資訊。OpenTelemetry SDK 預設使用 W3C 格式。部分 vendor 有自己的 header（Datadog 用 x-datadog-trace-id、AWS X-Ray 用 X-Amzn-Trace-Id），跨 vendor 時需要在 collector 層轉換。

使用情境

系統需要 trace context 的訊號是延遲或錯誤跨越多個服務。Checkout 變慢時，trace context 讓 tracing 系統把 API gateway、order service、payment service、database query 的 span 串成一條路徑，在 waterfall view 中直接看到時間花在哪。

Context 在 HTTP call、gRPC metadata、queue message header 上傳遞。Queue 邊界的 propagation 比 HTTP 複雜 — consumer 可能在 producer 之後很久才消費，context 的時間跨度從毫秒擴大到分鐘。

設計責任

Trace context 設計要處理四個邊界的傳遞：HTTP / gRPC（SDK auto-instrumentation 自動處理）、queue（需要 instrumented client 注入 message header）、thread pool（需要語言級的 context 傳播機制）、background job（需要在 job 啟動時建立 root span）。

斷鏈的常見原因和修復策略見 4.3 tracing 與 context link。Sampling 決策跟 trace context 的關係見 4.7 sampling 策略。

概念位置

Cardinality 是 metrics 設計的成本邊界。status、method、endpoint 常可接受；user_id、order_id、request_id 通常會讓時間序列爆炸，應放進 log 或 trace。 可先對照 Metrics。

可觀察訊號與例子

系統需要檢查 cardinality 的訊號是 metrics 儲存成本上升、查詢變慢、Prometheus 或後端儲存壓力升高。把 tenant_id 放進每個高流量指標前，要先評估 tenant 數量與查詢目的。

設計責任

Metrics 設計要先定義問題，再選 label。高基數資訊可以改用抽樣 log、trace attribute、top-N 指標或離線分析。

概念位置

Alert runbook 是可觀測性與操作流程的交界。告警搭配 runbook 後，事故處理可以從個人經驗轉成團隊流程。

可觀察訊號與例子

系統需要 alert runbook 的訊號是 on-call 收到告警後仍要臨場猜原因。Consumer lag 告警應連到 queue depth、error rate、下游 latency、dead-letter queue 數量與擴容或暫停流程。

設計責任

Runbook 要包含影響判斷、查詢連結、原因分類、立即緩解、回復驗證與升級路徑。每次事故後應更新 runbook，讓下一次處理更可重現。

概念位置

Authorization 是資料保護與操作安全的核心邊界。它可以用 role、permission、policy、tenant boundary、resource owner 或 attribute-based rule 表達。

可觀察訊號與例子

系統需要授權模型的訊號是角色、資料範圍或操作風險開始分級。客服可以查看訂單狀態，但調整退款、下載 PII 或修改權限應需要更高權限與 audit log。

設計責任

授權設計要定義主體、資源、操作、條件、拒絕原因與稽核欄位。測試要覆蓋跨 tenant 存取、低權限升級、高風險操作、function-level authorization 與資料匯出。

概念位置

Data masking 是資料分級與最小揭露的實作方式。完整身份證、信用卡、電話、email、地址與 access token 都可能需要依角色、情境與用途做不同遮罩。 可先對照 Data Reconciliation。

可觀察訊號與例子

系統需要 data masking 的訊號是資料會離開原本受控邊界。客服查詢頁可能只顯示部分電話；報表匯出可能需要核准與遮罩；log 應避免記錄完整 token。

設計責任

遮罩策略要定義欄位分級、角色權限、匯出規則、測試資料產生與 audit。遮罩 helper 應集中管理，讓不同服務與語言維持一致規則。

概念位置

Secret 是高風險操作能力。它們應集中放在受控系統中，並具備儲存位置、authorization、使用範圍、輪替週期、撤銷流程與 audit log。

可觀察訊號與例子

系統需要 secret management 的訊號是服務開始連接 database、broker、雲端 API 或第三方支付。Webhook signing secret 洩漏後，攻擊者可能偽造進站事件；database 密碼洩漏後，資料存取邊界會失效。

設計責任

Secret 管理要包含 least privilege、環境隔離、輪替演練、撤銷、版本管理與部署注入方式。Runbook 應說明疑似洩漏時如何停用、輪替、追查與恢復。

概念位置

TLS 是公開網路服務的基本傳輸保護。mTLS 常用在 service-to-service、內部 API、金融或高敏感資料傳輸場景，讓服務身份以憑證、authentication 與網路邊界共同判斷。

可觀察訊號與例子

系統需要 mTLS 的訊號是內部服務會傳遞付款、PII、企業資料或高權限操作。服務身份與憑證輪替納入設計後，橫向移動風險可以被更早偵測與限制。

設計責任

TLS / mTLS 設計要包含 website certificate lifecycle、ACME automation、certificate chain and trust root、certificate rotation and renewal、certificate revocation、過期 alert、測試環境與故障排查。憑證、private key 與相關 credential 應納入 secret management。

概念位置

Audit log 和一般 debug log 的責任不同。Debug log 幫助排查程式行為；audit log 保留安全與責任證據，因此需要更穩定的 schema、權限保護與保留策略。

可觀察訊號與例子

系統需要 audit log 的訊號是操作會影響權限、金錢、PII、合約或資料匯出。管理員調整角色、客服查看敏感資料、使用者匯出訂單、API key 輪替都應留下 audit record。

設計責任

Audit log 要包含 actor、action、resource、result、reason、request id、來源位置與時間。它也需要防竄改、查詢權限、retention 與 alert 規則。

概念位置

Timeout 是資源保護與失敗分類的基礎。等待時間上限讓 connection、worker、goroutine、thread、memory 與 request slot 可以釋放，降低單一慢依賴擴散成整體容量問題的機率。 可先對照 Database。

可觀察訊號與例子

系統需要 timeout 設計的訊號是 request latency 長尾變高、connection pool 等待增加、worker 長時間卡住或使用者重複送出操作。Checkout 呼叫付款 API 時，timeout 要短到能保護使用者流程，也要長到能涵蓋正常付款延遲。

設計責任

Timeout 要依呼叫目的分層設定。使用者 request、背景 job、database query、外部 API 與 graceful shutdown cleanup 應有不同時間上限；錯誤回報要標出 timeout 來源，讓 runbook 能定位是哪個依賴超時。

概念位置

Deadline 讓多層呼叫共享同一份時間預算。入口 request 若只剩 200ms，下游呼叫就應知道剩餘時間，並選擇快速回應、fallback、degradation 或停止開始昂貴工作。

可觀察訊號與例子

系統需要 deadline 的訊號是多個下游各自 retry policy，導致整體時間遠超使用者可接受範圍。搜尋 API 需要查庫存、價格與推薦時，deadline 可以讓每個下游根據剩餘時間調整策略。

設計責任

Deadline 要跨服務傳遞，並和 retry policy、fallback、cancellation 與 observability 對齊。Log 與 trace 應記錄 deadline exceeded、剩餘時間與造成超時的依賴。

概念位置

Backoff 是 retry policy 的節奏控制。固定間隔重試容易在下游尚未恢復時持續施壓；指數退避能讓重試從快速恢復逐漸轉成保守等待。 可先對照 Facet Query。

可觀察訊號與例子

系統需要 backoff 的訊號是下游服務短暫 timeout、rate limit 或重啟。通知服務呼叫第三方簡訊 API 失敗時，可以先快速重試一次，再逐步拉長間隔，避免所有 worker 持續打向同一個故障 API。

設計責任

Backoff 要搭配最大等待時間、最大重試次數、jitter 與錯誤分類。永久性錯誤應進入分類處理或 dead-letter；暫時性錯誤才適合退避重試。

概念位置

Jitter 是反同步尖峰工具。Exponential backoff 只會拉長間隔；若所有 client 同時開始、使用同一公式，下一波重試仍可能同時抵達。Jitter 讓這些重試分散。 可先對照 Least Privilege。

可觀察訊號與例子

系統需要 jitter 的訊號是整點、部署後、cache 過期後或故障恢復後出現同步流量尖峰。大量 worker 在同一秒重試失敗 job，可能讓剛恢復的下游再次被打滿。

設計責任

Jitter 要用在 retry delay、TTL、排程 job、polling interval 與 client reconnect。觀測上要看重試分布、尖峰流量與下游恢復時間。

概念位置

Retry storm 是 retry policy、timeout、backoff、jitter 與 rate limit 的共同風險。每一層服務若都自動重試，單一使用者 request 可能變成多倍下游呼叫。 可先對照 Rollback Rehearsal。

可觀察訊號與例子

系統需要防止 retry storm 的訊號是下游錯誤率上升後，request 數、連線數與 CPU 同步上升。付款 API 短暫變慢時，所有 checkout instance 同時重試，可能讓付款 API 更難恢復。

設計責任

Retry storm 防護要包含重試預算、backoff、jitter、rate limit、circuit breaker 與告警。Runbook 應能看出原始流量與重試流量的比例。

概念位置

Thundering herd 常出現在 cache 過期、鎖釋放、服務恢復、排程任務、client reconnect 與廣播通知。它和 cache stampede 相近，但範圍更廣，包含各種同時醒來與同時競爭。 可先對照 Timeout。

可觀察訊號與例子

系統需要處理 thundering herd 的訊號是故障恢復後流量突然高於平常數倍。WebSocket server 重啟後，所有 client 同時重連，可能讓 authentication、subscription 與 presence store 同時過載。

設計責任

常見策略包括 jitter、排隊、分批恢復、token bucket、singleflight、soft TTL 與 admission control。設計重點是把同步尖峰轉成可控分布。

概念位置

暫時性故障適合用 retry、backoff、jitter、timeout 與 fallback 吸收。它和永久性錯誤不同；payload schema 錯、權限拒絕、業務狀態不允許通常需要分類處理，而非持續重試。 可先對照 Tripwire。

可觀察訊號與例子

系統需要分辨 transient failure 的訊號是錯誤短暫升高後恢復。Redis failover 期間可能出現短暫連線錯誤；consumer 可以退避重試，但要控制重試量避免擴大故障。

設計責任

錯誤分類要標出 temporary、permanent、timeout、rate limited 與 dependency unavailable。Runbook 應說明哪些錯誤可以自動重試，哪些要進入 dead-letter 或人工處理。

概念位置

Partial failure 是降級、fallback、circuit breaker、failover 與 observability 的共同前提。設計要先承認某些功能會局部失效，再定義核心功能如何保留。 可先對照 Partition。

可觀察訊號與例子

系統需要 partial failure 設計的訊號是單一依賴失效會拖慢整體頁面。商品頁中推薦服務失效時，頁面仍可顯示商品資訊與購買按鈕；推薦區可以使用 fallback 或暫時空白。

設計責任

Partial failure 設計要分清核心路徑與輔助路徑。觀測資料要能按依賴、功能區塊、tenant、region 或 endpoint 顯示故障範圍。

概念位置

Cascading failure 是可靠性設計的主要防護目標。Timeout、backpressure、rate limit、circuit breaker、bulkhead 與 load shedding 都是在切斷擴散路徑。 可先對照 Certificate Chain and Trust Root。

可觀察訊號與例子

系統需要防 cascading failure 的訊號是原始故障在一個服務，症狀卻出現在多個上游。資料庫變慢後，API worker 卡住、queue lag 上升、retry 增加，最後登入與 checkout 都變慢。

設計責任

防護要從依賴圖出發，為每個下游設定 timeout、pool limit、重試預算與降級策略。Incident 後應檢查故障是如何跨服務擴散，而不只修復第一個壞掉的元件。

概念位置

Load shedding 是過載保護工具。它和 rate limit、backpressure、degradation、priority queue 與 admission control 相關；重點是先定義哪些工作可以被拒絕，哪些工作需要保留。 可先對照 Load Test。

可觀察訊號與例子

系統需要 load shedding 的訊號是流量尖峰超過服務容量。活動期間可以拒絕低優先的推薦刷新、延後報表產生，保留下單、付款與資料保存。

設計責任

Load shedding 要定義優先級、拒絕回應、重試建議、告警與使用者體驗。觀測上要記錄 shed count、原因、受影響 endpoint 與核心路徑是否恢復。

概念位置

Token bucket 常用於 rate limit、retry budget、API quota、worker admission 與下游保護。它同時表達平均速率與短暫尖峰容忍度。 可先對照 Token Revocation。

可觀察訊號與例子

系統需要 token bucket 的訊號是流量有短暫尖峰，但仍需要限制長期平均使用量。第三方 API 每秒可處理固定請求量時，worker 可以用 token bucket 控制呼叫速度。

設計責任

Token bucket 要定義補充速率、容量、消耗單位、超限行為與觀測欄位。多 tenant 系統還要區分全域 bucket 與 tenant bucket，保護公平性。

概念位置

Dependency isolation 是防止 cascading failure 的結構性設計。它可以透過獨立 pool、獨立 queue、bulkhead、timeout、rate limit 與 circuit breaker 實作。 可先對照 Deployment Contract。

可觀察訊號與例子

系統需要 dependency isolation 的訊號是某個低優先下游變慢後，高優先流程也跟著變慢。報表服務查詢很慢時，應讓它只耗用報表專用資源，checkout 的 database pool 則保留給核心交易流程。

設計責任

依賴隔離要先標出核心路徑、輔助路徑與共享資源。觀測上要能按依賴查看 pool 使用量、queue depth、timeout 與錯誤率。

概念位置

Bulkhead 是 dependency isolation 的具體模式。它常用在 thread pool、connection pool、queue、worker group、tenant capacity 與不同優先級工作。 可先對照 Burn Rate。

可觀察訊號與例子

系統需要 bulkhead 的訊號是單一功能或 tenant 可以拖垮整體服務。大量報表匯出可以放到獨立 worker pool，避免它佔滿處理登入、查詢與付款的資源。

設計責任

Bulkhead 設計要定義分艙邊界、容量、排隊策略、拒絕行為與告警。容量切分太細會降低利用率，切分太粗會失去隔離效果。

概念位置

Fallback 是 partial failure 與 degradation 設計的一部分。它能保留使用者流程，但也可能帶來 stale data、成本增加、結果品質下降或邏輯分歧。

可觀察訊號與例子

系統需要 fallback 的訊號是輔助依賴失敗時仍可提供核心價值。推薦服務失敗時，商品頁可以顯示熱門商品；付款服務失敗時，fallback 可能只允許保留訂單而暫停付款。

設計責任

Fallback 要明確標出使用條件、資料新鮮度、使用者文案、alert 與恢復條件。Fallback 路徑本身也需要測試與容量評估，因為事故時它會突然承受大量流量。

概念位置

Fail fast 常和 circuit breaker、validation、dependency health、rate limit 與 load shedding 搭配。它把已知會失敗的等待轉成可分類錯誤，讓上游可以選擇 fallback、重試或停止流程。 可先對照 Failover。

可觀察訊號與例子

系統需要 fail fast 的訊號是下游已知中斷，但上游仍持續等待。若 payment provider 已進入 circuit open，checkout 可以立即回應「付款暫停」或保留訂單，讓 request 快速進入明確結果。

設計責任

Fail fast 要提供清楚錯誤分類與使用者回應。對內錯誤要能區分 validation failure、dependency unavailable、quota exceeded 與 circuit open；對外回應要避免暴露敏感內部細節。

概念位置

Retry budget 是 retry storm 的防護工具。它可以用比例、token bucket、error budget、全域配額或每個 client 配額實作，讓重試量和正常流量維持合理比例。 可先對照 Retry Policy。

可觀察訊號與例子

系統需要 retry budget 的訊號是下游故障時重試流量比正常流量更大。搜尋服務 5% request timeout 時，如果所有 client 重試三次，下游實際壓力可能快速翻倍。

設計責任

Retry budget 要定義消耗規則、補充規則、超出預算後的行為與告警。觀測上要分開顯示原始 request、retry request、retry success 與 retry failure。

概念位置

Prefetch 是 broker backpressure 與 consumer fairness 的工具。Prefetch 太高會讓慢 consumer 囤積訊息；prefetch 太低會降低吞吐，讓 consumer 閒置等待。 可先對照 Probe。

可觀察訊號與例子

系統需要調整 prefetch 的訊號是 unacked messages 偏高、某些 consumer 忙碌但其他 consumer 閒置，或單筆工作耗時差異很大。影片轉檔工作長短差異大時，較低 prefetch 能讓工作更公平分配。

設計責任

Prefetch 要和 handler 耗時、並發數、ack timeout、下游容量與 retry policy 一起調整。觀測上要看 unacked messages、consumer utilization、處理耗時與 redelivery。

概念位置

In-flight 狀態是 consumer lifecycle 的中間階段。它連接 prefetch、ack timeout、redelivery、consumer crash 與 graceful shutdown。In-flight 訊息越多，代表系統有越多未完成副作用。 可先對照 In-Process Channel。

可觀察訊號與例子

系統需要觀察 in-flight 訊息的訊號是部署或故障期間出現大量重複處理。Consumer 收到訂單事件後還沒 ack 就 crash，broker 可能重新投遞該事件，因此 handler 需要 idempotency。

設計責任

Consumer shutdown 要先停止取新訊息，再處理或交回 in-flight 訊息。Runbook 應能看到 in-flight 數量、最久處理時間、redelivery 次數與 consumer crash 紀錄。

概念位置

Unacked message 是 queue health 的重要訊號。Queue depth 告訴團隊有多少訊息等著處理；unacked 則告訴團隊有多少訊息卡在 consumer 手上。 可先對照 Unrestricted Resource Consumption。

可觀察訊號與例子

系統需要追蹤 unacked 的訊號是 queue 看起來已分派，但產品結果仍然延遲。寄信 consumer 拿到大量訊息後卡在外部 SMTP API，queue ready 數不高，但 unacked 數會持續上升。

設計責任

Unacked 告警要和 prefetch、handler timeout、consumer health 與 downstream latency 一起看。Runbook 應說明何時重啟 consumer、何時調整 prefetch、何時暫停投遞。

概念位置

Redelivery 是 at-least-once delivery 的正常結果。它要求 consumer 具備 idempotency、處理紀錄、狀態檢查與可觀測欄位，讓重複進入的訊息維持同一個業務結果。 可先對照 Release Freeze。

可觀察訊號與例子

系統需要關注 redelivery 的訊號是同一事件被處理多次、retry count 上升或 dead-letter 增加。付款成功事件 redelivery 時，出貨 consumer 要能辨識該付款已處理。

設計責任

Redelivery 指標要記錄原因、次數與事件 ID。Consumer 測試應覆蓋首次處理、處理中 crash、redelivery 後命中已處理紀錄與永久失敗進 dead-letter。

概念位置

Requeue 是 nack / retry 流程的一種選擇。暫時性錯誤可以 requeue；永久性錯誤應進入 dead-letter 或人工處理流程。Requeue 需要搭配次數限制與 backoff。 可先對照 Resource Limit。

可觀察訊號與例子

系統需要控制 requeue 的訊號是同一訊息反覆進出 queue。外部 API 權限被拒絕時，requeue 只會重複失敗；網路短暫中斷時，requeue 搭配 backoff 可能成功。

設計責任

Requeue 設計要包含最大次數、錯誤分類、delay、dead-letter 條件與觀測欄位。Runbook 應能查出 requeue loop 的訊息與原因。

概念位置

Redelivery loop 是 retry policy 與 dead-letter 設計不足的訊號。它通常代表錯誤分類、最大重試次數、backoff 或 DLQ 條件缺失。 可先對照 Redelivery。

可觀察訊號與例子

系統需要處理 redelivery loop 的訊號是同一 message id 的 redelivery count 持續上升。某筆訂單事件 payload 缺少必要欄位時，每次處理都會失敗，應進入 dead-letter 等待修復。

設計責任

防護要包含 redelivery 次數上限、poison message 偵測、dead-letter、告警與 replay runbook。Consumer metrics 應能分辨新訊息處理量與重送訊息處理量。

概念位置

Poison message 是 queue pipeline 的隔離對象。系統要把它從主要處理路徑移開，讓正常訊息繼續前進，同時保留診斷資料給人工或修復流程。 可先對照 Post-Incident Review。

可觀察訊號與例子

系統需要 poison message 判斷的訊號是同一訊息每次投遞都失敗。新版 producer 多送一個 consumer 還不支援的 enum 值，可能讓舊版 consumer 持續失敗。

設計責任

Poison message 要進入 dead-letter，並保留 payload 摘要、schema version、錯誤類型、consumer version、correlation id 與重放條件。修復後才應 replay。

概念位置

Queue depth 是 queue health 的入口指標。Depth 上升可能代表 producer 變快、consumer 變慢、下游變慢、重試增加或 consumer 數量不足。 可先對照 Queue。

可觀察訊號與例子

系統需要 queue depth 告警的訊號是工作延遲會影響產品結果。通知 queue depth 持續上升時，使用者可能延遲收到信件；付款入帳 queue depth 上升時，帳務狀態可能延後更新。

設計責任

Queue depth 要和 consumer lag、oldest message age、processing rate、error rate 與 unacked messages 一起看。只看數量容易忽略訊息重要性與處理時間差異。

概念位置

Publisher confirm 是發布可靠性的下半段。Application 寫出事件後，仍需要確認 broker 是否承擔保存或投遞責任；若 confirm 失敗，producer 要重試、寫 outbox 或回報錯誤。 可先對照 Queue Contract。

可觀察訊號與例子

系統需要 publisher confirm 的訊號是事件遺失會造成後續流程漏執行。訂單付款後發布出貨事件時，producer 需要知道 broker 是否成功接收，否則倉儲服務可能永遠收不到事件。

設計責任

Publisher confirm 要搭配 timeout、retry、outbox 與 idempotency。觀測上要記錄 publish attempt、confirm latency、confirm failure 與未確認事件數。

概念位置

Persistence 是投遞保證與成本的取捨。正式訊息、付款事件、資料同步工作通常需要持久化；typing indicator、presence heartbeat 或即時狀態提示可以接受遺失。 可先對照 Message Protocol。

可觀察訊號與例子

系統需要 message persistence 的訊號是訊息遺失會造成產品後果。訂單付款事件遺失會造成出貨、通知或對帳漏掉；聊天室正在輸入提示遺失通常可以接受。

設計責任

Persistence 設計要和 queue durability、replication、retention、confirm、consumer ack 與成本一起評估。持久化降低遺失風險，也增加 IO、延遲與操作成本。

概念位置

Delivery mode 把產品語意轉成 broker 設定。正式訂單事件需要較高保證；即時狀態提示可以選擇低延遲、低保留的模式。 可先對照 Delivery Semantics。

可觀察訊號與例子

系統需要討論 delivery mode 的訊號是同一系統內有不同重要性的訊息。付款成功、庫存同步、推薦刷新、typing indicator 的失敗代價不同，應各自定義可靠性設定。

設計責任

Delivery mode 要由訊息語意決定，而非由 broker 預設值決定。設計文件應標出遺失、重複、延遲、順序與重放的可接受範圍。

概念位置

Consumer capacity 是 queue sizing 與容量規劃的基礎。Producer rate 高於 consumer capacity 時，queue depth 與 lag 會上升；consumer capacity 高於下游容量時，壓力會轉移到資料庫或 API。 可先對照 Consumer Group。

可觀察訊號與例子

系統需要估算 consumer capacity 的訊號是活動前要確認 queue 能否消化尖峰。通知服務每秒進入 5,000 筆任務，而 consumer 群組只能穩定處理 2,000 筆，lag 會持續累積。

設計責任

Capacity 設計要看平均耗時、p95 耗時、重試比例、下游限制與擴容速度。Runbook 應說明擴 consumer、調 prefetch、降級 producer 或暫停低優先訊息的條件。

概念位置

Competing consumers 是水平擴展 worker 的常見模式。它適合彼此獨立的工作，例如寄信、轉檔、縮圖、資料同步；對需要嚴格順序的工作，要額外設計 partition、key 或 single consumer。 可先對照 Config Rollout。

可觀察訊號與例子

系統需要 competing consumers 的訊號是單一 worker 處理速度追不上進入速度。報表產生任務彼此獨立時，可以增加 consumer 數；同一訂單的狀態事件則可能需要按 order id 保持順序。

設計責任

設計要定義工作是否可並行、是否需要順序、是否具備 idempotency，以及下游容量是否足夠。擴 consumer 前要確認 bottleneck 不在資料庫、外部 API 或全域 lock。

概念位置

Consumer group 是事件流跟多服務訂閱的協調模型。分析服務、搜尋索引服務、通知服務可以用不同 group 讀同一 topic — 每個 group 有自己的 offset 進度跟 consumer lag。

在 Kafka 中，consumer group 是一級概念、由 group coordinator 管理 partition 分配（rebalance）。在 Redis Streams 中對應 consumer group（XREADGROUP）。在 RabbitMQ 中沒有原生 consumer group — 多個 consumer 連到同一個 queue 就是 competing consumers、不同 queue 綁到同一個 exchange 就是 fan-out。

使用情境

系統需要 consumer group 的訊號是同一事件要被多個系統各自處理。訂單事件同時給出貨、通知與報表 — 三個 consumer group 各自有自己的處理速度、錯誤率跟重放流程。

Consumer group 的 rebalance（partition 重新分配）是 Kafka 生態的常見運維議題。Consumer 加入或離開 group 時觸發 rebalance、rebalance 期間 partition 暫時無人消費、造成短暫的處理停頓。Rebalance 時間跟 partition 數量、consumer 數量有關。

設計責任

Consumer group 要設計 group 名稱（跟服務名稱對齊、方便辨識）、offset / checkpoint 策略（auto-commit vs manual commit）、rebalance 行為（cooperative vs eager）、consumer lag 告警閾值與 replay runbook 權限。不同 group 的失敗應分開觀測跟處理 — 通知 group 落後不應影響出貨 group 的監控判讀。

概念位置

Partition 是 throughput、ordering 與 hot key 之間的取捨核心。它跟 topic 的關係是：topic 是邏輯分類（order events、payment events），partition 是 topic 內的物理分片。Partition key 決定同一類事件會落到哪個 partition；選錯 key 會造成 hot partition（單一 partition 過載）或讓需要順序的事件被拆散。

在 Kafka 中 partition 是一級概念；RabbitMQ 沒有原生 partition（用多個 queue + consistent hash exchange 模擬）；SQS 沒有顯式 partition（內部自動分片）。

使用情境

系統需要 partition 設計的訊號是事件量大且需要水平擴展處理能力。訂單事件可以用 order_id 作為 partition key，讓同一訂單的事件保留順序；若所有高流量商家的訂單都 hash 到同一個 partition，會形成 hot partition。

Partition 數量也影響 offset 管理的複雜度 — 每個 partition 有獨立的 offset，consumer group 的 rebalance 要重新分配 partition ownership。

設計責任

Partition 設計要定義 partition key（通常是業務實體 ID）、partition 數量（建議初期設多一點，Kafka partition 數量只能增加不能減少）、順序需求（同 key 保序 vs 全域保序）與 lag 觀測（per-partition lag 能定位 hot partition）。重新分 partition 可能影響順序、consumer group 配置與 replay 範圍。

概念位置

Offset 是 consumer group 的進度記錄、consumer lag 的計算基準、replay runbook 的起點定位。在 Kafka 中，offset 是每個 partition 內的遞增整數；在 Redis Streams 中是 entry ID（timestamp-sequence）；在 SQS 中沒有顯式 offset，改用 visibility timeout 控制消費進度。

Offset 提交太早（處理前就 commit）可能造成處理遺失 — consumer crash 後從已 commit 的位置繼續，跳過未完成的訊息。提交太晚（處理完成很久才 commit）可能造成重複處理 — consumer crash 後從舊 offset 重新開始，重複處理已完成的訊息。

使用情境

系統需要理解 offset 的訊號是 consumer 重啟後需要接續處理。報表 consumer 處理到某個 offset 後 crash，重啟時要從安全位置繼續，並用 idempotency 承受可能重複的事件。

Offset 也是 replay 操作的控制參數。「重設 offset 到三天前」意味著 consumer group 會從三天前的位置重新處理所有事件 — 下游需要有 idempotent 設計才能承受重播。

設計責任

Offset 提交策略要和業務處理完成條件對齊。Auto-commit（定期自動提交）實作簡單但在 crash 時有遺失風險；manual commit（處理完成後手動提交）更安全但程式碼更複雜。Runbook 應說明如何查 current offset、committed offset、lag、重設 offset 的操作步驟與 replay 對下游的影響。

概念位置

Retention 連接資料生命週期跟查詢能力。不同類型的資料需要不同保留期限 — log 的 debug 用途可能只需要 7 天、audit log 因合規要求可能需要 1 年以上、metrics 的 raw data 可能保留 15 天但 rollup 保留 90 天。

Retention 跟 storage tiering 搭配運作 — hot tier 保留最近的高精度資料、warm / cold tier 保留較舊的低精度或歸檔資料。保留期限的設定見 4.7 cardinality 與成本邊界 的保留階梯段。

使用情境

系統需要 retention 設計的訊號是事故排查或資料修復需要回看歷史。若 event stream 只保留 24 小時，三天前的錯誤就無法靠 replay 重建。反過來，無限保留會讓儲存成本持續成長。

設計責任

Retention 要同時考慮成本（儲存 × 時間）、法規（合規要求的最短保留期跟 GDPR 要求的最長保留期可能衝突）、資安（高敏感資料保留越久風險越高）、replay 需求（MQ 的 retention 影響 consumer 的 catchup 能力）跟 debug 能力（retention 太短讓事後分析無資料可用）。不同訊號類型用不同 retention 是基本做法 — error log 保留比 debug log 長、audit log 保留比 operational log 長。

概念位置

Online migration 是 release、database、observability 與 rollback 的共同工程。它通常搭配 Expand / Contract、backfill、dual write、shadow read、cutover 與 correctness check。

可觀察訊號與例子

系統需要 online migration 的訊號是資料量大、停機代價高或 rolling update 期間新舊版本會共存。把會員資料從舊 table 搬到新 table 時，服務仍要能註冊、登入與更新會員資料。

設計責任

Online migration 要設計階段、監控、速率限制、回滾、資料比對與停止條件。每個階段都要能獨立驗證，並保留回到前一階段的路徑。

概念位置

Cutover 連接資料正確性、部署、觀測與 rollback。切換可以一次完成，也可以用 feature flag、百分比流量、tenant 分批或讀寫分離逐步進行。 可先對照 Dashboard。

可觀察訊號與例子

系統需要 cutover 計畫的訊號是新舊系統都已準備好，但正式流量尚未切換。把搜尋索引換到新 cluster 時，可以先 shadow read 比對結果，再分批把讀取流量切過去。

設計責任

Cutover runbook 要包含前置檢查、切換步驟、觀測指標、停止條件、rollback 條件與負責人。切換後要持續監控錯誤率、延遲、資料差異與使用者回報。

概念位置

Fallback plan 是 release 與 migration 的風險控制。Rollback 是回到舊版本；fallback plan 可以包含暫停流量、切回舊路徑、凍結寫入、啟動維護模式或人工處理。 可先對照 Fallback。

可觀察訊號與例子

系統需要 fallback plan 的訊號是變更會影響資料正確性或核心流量。新付款 provider 上線後錯誤率升高，團隊需要知道如何切回舊 provider、如何處理已送出的交易、如何對帳。

設計責任

Fallback plan 要在變更前完成，並明確列出觸發條件、執行者、資料影響、外部溝通與驗證方式。高風險變更應在預備環境演練。

概念位置

CDC 是資料同步與事件化的橋樑。它通常從 database log、trigger、polling 或平台工具取得變更，再轉成可由 consumer 處理的事件流。

可觀察訊號與例子

系統需要 CDC 的訊號是正式資料更新後，多個衍生系統都需要同步。會員資料變更後，搜尋、推薦、報表與客服系統可能都需要收到更新。

設計責任

CDC 設計要處理順序、duplicate delivery、schema 變更、backfill、lag、replay runbook 與 data masking。觀測上要看 capture lag、delivery lag、錯誤率與最舊未同步資料時間。

概念位置

Replication lag 是資料一致性與讀取路徑的風險指標。讀 replica 可以降低正式 database 壓力，但 lag 會讓剛寫入的資料在副本上暫時看不到。

可觀察訊號與例子

系統需要 replication lag 觀測的訊號是使用者寫入後立刻讀取。使用者更新地址後，客服後台若讀 replica，可能短時間內仍看到舊地址；付款與出貨流程則應讀 source of truth。

設計責任

Lag 設計要定義可接受延遲、讀取路徑、強一致需求與 fallback。觀測上要能看每個 replica、index 或 stream pipeline 的 lag 與最舊未同步資料。

概念位置

Checkpoint 是恢復能力與重放安全的基礎。它可以是 offset、時間戳、primary key、batch id、file position 或業務狀態。 可先對照 CI Pipeline。

可觀察訊號與例子

系統需要 checkpoint 的訊號是工作需要分批完成或可能中途停止。Backfill 會員資料跑到第 300 萬筆時部署中斷，checkpoint 讓下一次從安全位置繼續。

設計責任

Checkpoint 要和處理完成條件對齊。提交太早可能遺失工作，提交太晚可能重複處理；因此 handler 需要 idempotency 或可重入設計。

概念位置

Backfill 是資料遷移的執行階段。它會消耗資料庫、cache、queue、CPU 與網路資源，因此需要速率限制、checkpoint、監控與停止條件。 可先對照 Backpressure。

可觀察訊號與例子

系統需要 backfill 的訊號是新欄位對新資料有效，但舊資料尚未填滿。會員資料新增 country_code 後，需要從地址或外部資料補算舊會員欄位。

設計責任

Backfill 要分批執行，並記錄進度、錯誤、重試與資料差異。高風險 backfill 應先抽樣驗證，再逐步擴大範圍。

概念位置

Dual write 是高風險一致性模式。兩個寫入目標很難共享同一個 transaction，因此可能出現一邊成功、一邊失敗，或兩邊順序不同。 可先對照 Duplicate Delivery。

可觀察訊號與例子

系統需要 dual write 風險評估的訊號是 migration 期間新舊資料都要保持更新。會員資料同時寫舊資料庫與新資料庫時，任一邊 timeout 都可能造成資料分裂。

設計責任

Dual write 要搭配 outbox、reconcile、correctness check、重試與 fallback plan。設計文件應說明哪一邊是 source of truth，以及不一致時如何修復。

概念位置

Shadow read 是 migration 與服務替換的驗證工具。它能在不影響使用者結果的前提下收集新舊差異，但會增加下游流量與資料存取成本。 可先對照 Migration Gate。

可觀察訊號與例子

系統需要 shadow read 的訊號是新讀取路徑即將接正式流量。搜尋服務換新索引前，可以用正式查詢同時查新索引，記錄結果差異但仍回傳舊索引結果。

設計責任

Shadow read 要控制採樣率、timeout、資料遮罩、差異記錄與成本。它的結果應進入 correctness dashboard，並作為 Migration Gate 的依據。

概念位置

Correctness check 是 migration、refactoring、shadow read、backfill 與 cutover 的決策依據。沒有正確性檢查，團隊只能憑錯誤率或使用者回報判斷新系統。 可先對照 Migration Gate。

可觀察訊號與例子

系統需要 correctness check 的訊號是新舊系統會並行一段時間。價格計算服務重寫後，要比對總價、折扣、稅額、幣別與 rounding 規則，而不只是比對 response 字串。

設計責任

Correctness check 要定義比對欄位、容忍差異、抽樣策略、錯誤分類與停止條件。高風險差異要能追到 request id、資料版本與規則版本，並作為 Migration Gate 的依據。

概念位置

Completeness 是資料品質的一部分。Migration、backfill、報表、audit、搜尋索引與機器學習資料集都需要確認資料是否完整。 可先對照 Migration Gate。

可觀察訊號與例子

系統需要 completeness check 的訊號是資料遷移完成後仍可能缺漏。訂單資料搬遷時，除了 row count，也要確認 order items、付款紀錄、退款紀錄與狀態歷史是否完整。

設計責任

Completeness 檢查要包含總量、分群、時間範圍、關聯完整性與抽樣。結果應進入 Migration Gate，並留下可重跑的查詢或報表。

概念位置

Reconciliation 是 eventual consistency 的修復流程。即使系統設計了事件、retry policy 與 outbox pattern，仍需要定期或事件後比對正式結果，修復漏送、重複或半成功。

可觀察訊號與例子

系統需要 reconciliation 的訊號是兩個系統都聲稱有狀態，但結果可能不同。付款 provider 顯示已扣款，訂單系統顯示未付款時，需要對帳流程依 source of truth 判斷正式結果並修復訂單狀態。

設計責任

Reconciliation 要定義比對來源、優先權、差異分類、修復動作、audit log 與人工介入條件。高風險資料要保留修復前後的證據。

概念位置

Hit / miss 是快取效益的基礎訊號。Hit 越高，通常表示下游讀取壓力越低；miss 上升可能來自 TTL 太短、eviction、key 設計錯誤、流量型態改變或資料剛被清除。 可先對照 Cache Hit Rate。

可觀察訊號與例子

系統需要觀察 hit / miss 的訊號是快取導入後仍然沒有降低資料庫壓力。熱門商品頁若 miss rate 高，資料庫仍會承受大量查詢。

設計責任

Hit / miss 指標要按 key pattern、endpoint、tenant 或資料類型切分。Runbook 應說明 miss 上升時如何檢查 TTL、eviction、cache invalidation 與 cache stampede。

概念位置

Hit rate 是容量與成本指標。低 hit rate 可能代表快取資料不適合、key 太分散、TTL 太短、資料經常失效或工作負載不重複。 可先對照 Cache Invalidation。

可觀察訊號與例子

系統需要 hit rate 的訊號是 Redis 成本上升但資料庫壓力仍高。若搜尋結果每次 query 都不同，快取命中率可能很低；商品詳情這類重複讀取則更適合快取。

設計責任

Hit rate 要搭配 latency、下游 query count、cache size 與資料新鮮度一起看。高 hit rate 也要確認資料正確性，因為過期資料命中仍可能造成產品問題。

概念位置

Warmup 是快取與部署流程的交界。新 instance、Redis 清空、熱門活動開始或版本切換時，快取可能是空的；warmup 可以先建立高價值資料。 可先對照 Cascading Failure。

可觀察訊號與例子

系統需要 warmup 的訊號是部署後前幾分鐘 latency 升高，或活動開始時資料庫突然被打滿。大型促銷前，可以預先載入熱門商品、價格與庫存摘要。

設計責任

Warmup 要定義資料來源、載入順序、速率限制、失敗行為與 readiness 關係。Warmup 本身也會產生下游流量，因此要納入容量規劃。

概念位置

Prefetching 是預測型快取策略。它適合可預期的讀取，例如下一頁資料、熱門商品、使用者登入後常用設定或活動頁資源。 可先對照 Cache Stampede。

可觀察訊號與例子

系統需要 prefetching 的訊號是使用者行為有穩定下一步。影片平台可以在使用者接近播放結束時預載下一集資訊；電商可以在活動頁預載熱門商品摘要。

設計責任

Prefetching 要控制準確率、容量成本、資料新鮮度與下游壓力。預載錯誤資料會浪費 cache 空間，預載過多會擠出真正熱門資料。

概念位置

Cold start 是部署、autoscaling、cache warmup 與 readiness 的共同問題。新 instance 若尚未建立連線、載入設定或暖好 cache，就接正式流量，可能造成延遲尖峰。 可先對照 Competing Consumers。

可觀察訊號與例子

系統需要處理 cold start 的訊號是擴容後新 instance 的 latency 明顯高於舊 instance。活動流量來臨時自動擴容，若新 instance 都在建立連線與載入 cache，可能無法立即承擔流量。

設計責任

Cold start 設計要包含 readiness、warmup、連線預建、流量緩啟與觀測。Autoscaling 設定要考慮啟動到可接流量的真實時間。

概念位置

Write-through 是寫入路徑上的快取策略。它適合更新頻率可控、讀取頻繁且資料新鮮度重要的場景；寫入延遲會因同步更新快取而增加。 可先對照 Write-Behind Cache。

可觀察訊號與例子

系統需要 write-through 的訊號是寫入後立刻讀取很常見。使用者更新個人設定後，下一個 request 通常會立刻讀取設定摘要；同步更新快取可以降低讀到舊資料的機率。

設計責任

Write-through 要定義正式來源寫入與快取寫入的錯誤處理。快取寫入失敗時，系統要決定回報失敗、刪除快取、延後修復或讓下一次讀取重建。

概念位置

Write-behind 是延後持久化策略。它適合可重建、可補償或低風險資料；金流、訂單正式狀態與權限資料通常需要更強保證。 可先對照 Data Reconciliation。

可觀察訊號與例子

系統需要評估 write-behind 的訊號是寫入流量很高、正式來源寫入成本高，且短暫延遲可接受。使用者行為計數或 analytics event 可以先進緩衝層，再批次寫入儲存。

設計責任

Write-behind 要處理 buffer durability、flush、retry、checkpoint、資料遺失、停機與 Data Reconciliation。Runbook 應能查看尚未 flush 的資料量與最舊等待時間。

概念位置

Stale data 是一致性與使用者體驗的交界。某些資料過期可接受，例如推薦列表；某些資料過期會造成交易或安全問題，例如價格、庫存、權限。 可先對照 Status Page。

可觀察訊號與例子

系統需要 stale data 設計的訊號是使用者在不同頁面看到不同狀態。商品列表顯示舊價格，結帳頁顯示新價格，這需要明確定義哪個頁面可以接受延遲。

設計責任

Stale data 策略要定義可接受延遲、正式來源、顯示文案、強制刷新與修復流程。高風險資料應避免長時間依賴 stale 副本。

概念位置

Soft TTL 把過期分成可用刷新期與硬過期點。資料進入刷新期後仍可回應部分 request，並由背景流程重建；到達硬過期點後則停止使用該副本。 可先對照 Source of Truth。

可觀察訊號與例子

系統需要 soft TTL 的訊號是熱門資料過期時大量 request 同時打向正式來源。熱門排行榜可以在 soft TTL 到期後先回傳舊榜單，同時觸發背景刷新。

設計責任

Soft TTL 要定義最大 stale 時間、刷新 owner、失敗重試與使用者可接受程度。觀測上要看 stale response 次數、刷新耗時與刷新失敗率。

概念位置

Singleflight 是 cache stampede 與 thundering herd 的防護工具。它適合相同 key、相同結果、短時間內大量重複請求的場景。 可先對照 SLI / SLO。

可觀察訊號與例子

系統需要 singleflight 的訊號是熱門 key 過期後，同時有大量 request 查同一筆資料。商品詳情 cache miss 時，只需要一個 request 回資料庫查詢，其他 request 等待同一結果。

設計責任

Singleflight 要定義 key、等待 timeout、錯誤分享策略與結果快取方式。若下游查詢失敗，系統要決定所有等待者都失敗，或部分使用 stale data。

概念位置

Histogram 是 metrics 中描述分布的工具，跟 counter（計數）跟 gauge（瞬間值）互補。Average 只能說明中心趨勢；histogram 可以支援 percentile（p95 / p99）、SLI 計算跟 burn rate 判斷。

Prometheus 的 histogram 用累積 bucket（le label）實作 — 每個 bucket 記錄「值 <= le 的觀測次數」。PromQL 的 histogram_quantile() 從 bucket 資料估算 percentile。

使用情境

系統需要 histogram 的訊號是少數慢 request 會影響使用者體驗但 average 看不出來。Checkout 平均延遲 100ms 看起來良好，但 p99 若超過 3 秒，1% 的使用者體驗極差。Histogram 讓這個長尾可見。

設計責任

Histogram bucket boundary 要依 SLO 閾值跟實際延遲範圍設計。Bucket 太粗（只有 100ms / 500ms / 1s）會讓 percentile 估計跳躍式變化；太細會增加 cardinality（每個 bucket 是一條 time series）。常見做法是在 SLO 閾值附近密集、在兩端稀疏。詳見 4.2 metrics basics。

概念位置

Bucket 是 histogram 可用性的關鍵。Bucket 應圍繞 SLO 門檻與常見延遲分布設計；錯誤 bucket 會讓 dashboard 看起來有資料，卻回答不了服務是否達標。 可先對照 Buffer。

可觀察訊號與例子

系統需要調整 bucket 的訊號是 p95 / p99 查詢不穩，或 SLO 門檻附近缺乏解析度。若 checkout SLO 是 300ms，bucket 應在 100ms、200ms、300ms、500ms 附近提供足夠區分。

設計責任

Bucket 設計要平衡解析度與 cardinality。不同 endpoint 或任務類型可能需要不同 bucket，但過多自訂 bucket 會增加儲存與查詢成本。

概念位置

Percentile 跟 histogram 搭配使用。Histogram 記錄延遲分布（哪些 bucket 收到多少 request），percentile 從 histogram 資料計算（histogram_quantile in PromQL）。Average latency 看不到長尾 — 平均 80ms 但 p99 是 2 秒，代表 1% 的使用者體驗極差。

Percentile 是 SLI 的常見型別 — latency SLI 用「p99 < 500ms 的 request 佔比」量化使用者體驗。

使用情境

系統需要 percentile 的訊號是 average latency 穩定但使用者仍回報卡頓。搜尋 API 平均 80ms、p99 2 秒，表示少數 request 走到慢查詢或下游 timeout。高流量服務的 1%（p99 以外）可能代表數千個使用者。

設計責任

Percentile 要搭配 histogram bucket 設計 — bucket boundary 決定 percentile 計算的精度。Bucket 太少（只有 100ms / 500ms / 1s）會讓 p99 的估計跳躍式變化。Bucket 太多會增加 cardinality。低流量服務的高 percentile 容易受少量樣本影響，alert 閾值要考慮統計穩定性。詳見 4.2 metrics basics 跟 4.6 SLI/SLO 訊號設計。

概念位置

Error budget 把可靠性討論轉成可量化的決策語言。Budget 消耗過快時，團隊應暫停高風險變更、優先修可靠性；budget 充足時，可以承擔更多變更風險跟 experiment。

Error budget 是 burn rate alerting 的基礎 — burn rate 量化的是 error budget 被消耗的速度。Error budget 接近耗盡時，進入 release gate 的 freeze 條件。

使用情境

系統需要 error budget 的訊號是發版速度與事故風險需要共同管理。Checkout 服務本月多次 timeout，若 error budget 已接近耗盡，團隊應暫停高風險變更直到 budget 恢復。

設計責任

Error budget 的 metric 結構需要 rolling window 的 total requests 跟 failed requests（見 4.6 SLI/SLO 訊號設計）。Budget remaining 作為 dashboard panel 跟 release gate 的輸入 — 用 recording rule 維護 rolling window 計算，避免每次查詢掃描 30 天的 raw data。

概念位置

Burn rate 是 SLO alerting 的核心機制，把 SLI 的 error ratio 轉成可行動的嚴重度判斷。短時間高 burn rate（14x、5 分鐘窗口）代表急性事故；長時間中等 burn rate（1x、數小時窗口）代表慢性可靠性退化。

Burn rate alerting 比固定閾值 alert 更能反映使用者影響 — 低流量時段的幾筆 error 可能 burn rate 很低（對 error budget 影響小），高流量時段的相同 error rate 可能 burn rate 很高（影響大量使用者）。

使用情境

系統需要 burn rate 的訊號是固定閾值 alert（error rate > 1%）在不同流量時段的表現不穩定 — 低流量時 false alarm、高流量時漏報。Burn rate 自動適應流量基線。

設計責任

Burn rate alerting 用 multi-window 策略：短窗口（5min）抓急性 + 長窗口（1hr）做確認，兩個窗口都超過閾值才觸發。Recording rule 預計算各窗口的 error ratio，讓 alert evaluate 讀預計算結果而非重算 raw series。完整設計見 4.6 SLI/SLO 訊號設計。

概念位置

Sampling 是觀測成本控制工具。它可以是固定比例、依錯誤保留、依延遲保留、依 tenant 保留或 adaptive sampling。 可先對照 Schema Migration。

可觀察訊號與例子

系統需要 sampling 的訊號是 trace 或 log 成本隨流量快速成長。Checkout 成功 request 可低比例採樣，錯誤與高延遲 request 則應提高保留率。

設計責任

Sampling 要定義保留規則、偏差、查詢限制與事故期間調整方式。抽樣後的資料適合診斷趨勢，但某些 audit 或法規資料需要完整保留。

監控 SDK 中靜態取樣和動態取樣（背壓觸發）的具體實作見 監控知識卡：Sampling。

概念位置

Correlation ID 跟 trace id 的定位不同。Trace id 偏向一次技術呼叫路徑（一個 HTTP request 經過多個服務）；correlation ID 可以代表更長的業務流程（一筆訂單從建立到付款到出貨，跨越多個獨立 request）。

Correlation ID 是 log schema 的核心欄位。Log 帶 correlation ID 時，跨服務跟跨 async 邊界的事件可以用同一個 ID 查出完整業務流程。見 4.1 log schema。

使用情境

系統需要 correlation ID 的訊號是事故排查需要跨同步與非同步邊界。訂單建立 request、付款事件、寄信 job 與出貨事件共享同一 correlation ID，讓客服跟工程師追到完整流程。

設計責任

Correlation ID 要在入口（API gateway 或 first service）建立或從 upstream 接收，並傳遞到 log、message header、trace context 與外部呼叫。欄位名稱要穩定（跨服務一致，避免 request_id vs req_id vs requestId 的漂移），避免把敏感資料當成 ID。

概念位置

Request ID 是同步 request 診斷的基本欄位。它通常比 trace 簡單，適合放在 log、response header 與客服查詢流程中。 可先對照 API Gateway。

可觀察訊號與例子

系統需要 request ID 的訊號是使用者回報錯誤時，工程師需要快速找到對應 log。錯誤頁顯示 request ID，客服可以把 ID 交給工程師查完整處理路徑。

設計責任

Request ID 要在入口統一產生或接受可信上游傳入，並在 response、log、trace 與下游呼叫中保留。安全設計要避免讓外部可控 ID 汙染內部查詢或造成 spoofing。

概念位置

Trace ID 是 tracing 的頂層關聯欄位。W3C Trace Context 標準使用 128-bit 隨機值（32 hex chars）；部分 vendor 使用 64-bit（Datadog 舊版、Zipkin v1）。混用不同長度時需要在 collector 層做 ID 轉換或 padding。

Trace ID 跟 request id 的定位不同：request id 是單一服務內的請求識別碼（通常由 API gateway 或 load balancer 產生），trace id 是跨服務的追蹤識別碼（由第一個 instrumented service 產生）。兩者可以共存在同一筆 log 的不同欄位，各自服務不同的查詢需求。

使用情境

Trace ID 的診斷價值是「拿到一個 ID 就能看到整條 request 路徑」。事故中從 error log 拿到 trace ID，貼進 tracing UI（Jaeger、Grafana Tempo、Datadog APM），直接看 waterfall view 定位瓶頸。

Trace ID 也是 log / metric / trace 三者的關聯樞紐。Log 的結構化欄位帶 trace ID 時，debug 工作流可以從 log → trace 或 trace → log 雙向跳轉。Metric 的 exemplar 帶 trace ID 時，可以從 dashboard 的 latency spike 跳到具體的高延遲 trace。

設計責任

Trace ID 要透過 trace context 在 HTTP header、queue message header、thread context 上傳遞。Log 層面，trace ID 應作為必要欄位寫入 structured log（見 4.1 log schema）。Sampling 策略要確保錯誤與高延遲 trace 有足夠保留率，避免事故時 trace ID 存在於 log 但對應的 trace 資料已被 sampling 丟棄。

概念位置

Span 是 tracing 的基本單位。HTTP handler、database query、cache call、broker publish、consumer handle 與外部 API 呼叫都可以形成 span。Span 之間透過 parent-child 關係組成 tree — 共享同一個 trace id 的所有 span 構成一條完整的 trace。

Span 有四種 kind：CLIENT（發起呼叫）、SERVER（接收呼叫）、PRODUCER（投遞訊息）、CONSUMER（消費訊息）。Kind 影響 trace backend 怎麼計算 service-to-service 的延遲跟依賴方向。

使用情境

系統需要 span 的訊號是單一 request 裡有多個步驟，需要知道哪一步變慢或出錯。Checkout trace 中 payment span 佔 80% 時間，問題焦點就落在付款依賴或其網路路徑。

設計責任

Span 設計要控制名稱粒度、屬性選擇、錯誤狀態與敏感資料。Span 名稱太粗（所有 HTTP call 都叫 HTTP）會看不出瓶頸；太細（每個 URL path parameter 都獨立命名）會讓 span 名稱成為無界維度、影響 trace backend 的聚合效能。

屬性要帶足夠的診斷資訊但避免敏感資料。http.url 帶完整 URL 可能含 query parameter 裡的 token；db.statement 帶完整 SQL 可能含使用者資料。需要在 SDK 或 collector 層做 redaction。

概念位置

Symptom-based alert 跟 cause-based alert 分工不同。CPU 高、queue depth 高、GC 頻繁是可能的原因；checkout 失敗率升高才是直接的產品症狀。Symptom-based 適合 critical severity（page on-call），cause-based 適合 warning severity（工作時間排入 task）。

Symptom-based alert 是 4.4 dashboard-alert 建議的 alert 設計起點 — 先確認使用者是否受影響、再看系統原因。

使用情境

系統需要 symptom-based alert 的訊號是 on-call 被大量低層訊號吵醒，但無法判斷使用者是否受影響。付款成功率下降應立即告警；單台 instance CPU 高則可先進 dashboard 觀察或走自動修復流程。

設計責任

Symptom-based alert 要連到 SLI / SLO、runbook 與影響判斷。SLO-based alerting 用 burn rate 量化症狀嚴重度 — 「error budget 消耗速度是允許值的 14 倍」比「error rate > 1%」更能反映使用者影響規模。完整設計見 4.6 SLI/SLO 訊號設計。

概念位置

Runbook link 是 observability UX 的一部分。它把 alert、dashboard、log query、rollback、擴容、停用 feature 與升級聯絡方式串起來。

可觀察訊號與例子

系統需要 runbook link 的訊號是告警發出後，處理者仍要在聊天紀錄或文件庫中找下一步。Consumer lag 告警應直接連到 lag dashboard、DLQ 查詢、擴容指令與 replay runbook 注意事項。

設計責任

Runbook link 要保持有效、可搜尋、版本化。每次事故後應確認連結是否真的支援當次處理，並補上缺少的查詢與判斷條件。

概念位置

Alert fatigue 是可觀測性設計的失敗模式，跟 alert 的品質治理直接相關。告警應代表需要人介入的產品風險；其他訊號可以進 dashboard、ticket、報表或自動修復流程。

常見的 fatigue 來源：false positive（條件觸發但實際沒問題）、redundant alert（同一問題觸發多個 alert）、stale alert（條件已不適用但 rule 沒更新）。

使用情境

系統需要治理 alert fatigue 的訊號是 noise rate > 30%（超過三成的 alert 不需要行動），或 on-call 工程師反應「收到 alert 先 ack 再看、有時直接 resolve 不看」。

設計責任

Alert fatigue 的治理包括：追蹤 noise rate（on-call ack 時標記 actionable / noise）、定期審視高 noise 的 alert rule（調整閾值、改 symptom-based、加 inhibition、或刪除）、用 grouping 跟 inhibition 減少同一問題的重複通知。治理節奏跟 4.8 訊號治理閉環 整合。

概念位置

Authentication 是 authorization 的前置條件。系統先確認身份，再判斷該身份能否操作某個資源。身份確認失敗時，後續權限判斷缺少可靠基礎。

可觀察訊號與例子

系統需要 authentication 設計的訊號是服務需要區分使用者、管理員、service account 或第三方系統。Webhook 進站可以用 signature 驗證來源；service-to-service 可以用 mTLS 或 workload identity。

設計責任

Authentication 要處理 credential 保存、過期、撤銷、輪替、錯誤回應、登入風險與 audit log。安全事件後要能追查是哪個身份與 credential 被使用。

概念位置

BOLA 是 API 安全中常見的授權問題。Authentication 只能確認呼叫者身份；每次讀寫訂單、檔案、帳戶、發票或 tenant 資源時，仍要檢查該身份是否能操作該物件。 可先對照 BOPLA。

可觀察訊號與例子

系統需要 BOLA 防護的訊號是 API path 或 body 中包含資源 ID。使用者把 /orders/1001 改成 /orders/1002 時，系統必須確認 1002 是否屬於該使用者或其 tenant。

設計責任

BOLA 防護要在 usecase 或 policy 層檢查 resource ownership、tenant boundary 與角色權限。測試要覆蓋跨使用者、跨 tenant、低權限操作與猜測 ID。

概念位置

BOPLA 是 field-level policy 的安全問題。訂單物件可以讓使用者查看商品與金額，但內部風控欄位、成本、客服註記或權限欄位需要更高權限。 可先對照 Broker。

可觀察訊號與例子

系統需要 BOPLA 防護的訊號是 API 回傳完整資料模型，或允許 client 送入任意欄位。使用者更新個人資料時，外部輸入欄位應排除 role、is_admin 或 credit_limit。

設計責任

BOPLA 防護要定義欄位分級、輸入白名單、輸出 schema、遮罩與測試。公開 API DTO 應和內部資料模型分開。

概念位置

Mass assignment 是 API 輸入邊界問題。它常出現在直接把 JSON body bind 到 ORM model、domain model 或 persistence model 的程式碼中。 可先對照 Message Persistence。

可觀察訊號與例子

系統需要防 mass assignment 的訊號是 request body 可以包含內部欄位。註冊 API 若直接綁定 User model，攻擊者可能加入 role: admin 或 email_verified: true。

設計責任

防護要使用輸入 DTO、欄位白名單、policy validation 與測試。外部 request schema 應只包含該操作允許修改的欄位。

概念位置

資料暴露是輸出邊界問題。API response 應依用途設計 DTO、欄位遮罩與角色權限，內部資料模型應留在服務邊界內。 可先對照 Expand / Contract。

可觀察訊號與例子

系統需要防 excessive data exposure 的訊號是 response 包含敏感欄位、內部狀態或其他角色才需要的資料。客服 API 可以看部分電話；一般使用者訂單 API 則應只回傳使用者完成操作所需欄位。

設計責任

防護要包含 response schema、欄位分級、data masking、contract test 與 log 檢查。資料一旦回傳給 client，就應視為已暴露。

概念位置

資源消耗限制連接 rate limit、payload limit、timeout、pagination、query cost、queue quota 與 tenant quota。它同時是可靠性與資安問題。 可先對照 Validation Middleware。

可觀察訊號與例子

系統需要資源消耗限制的訊號是 API 支援搜尋、匯出、上傳、批次操作或複雜 filter。未限制日期範圍的報表匯出，可能讓單一 request 掃描多年資料。

設計責任

防護要定義大小限制、速率限制、分頁、查詢成本、timeout、租戶配額與告警。錯誤回應應告訴 client 如何縮小請求。

概念位置

Function-level authorization 和 object-level authorization 互補。Object-level 檢查資源歸屬；function-level 檢查操作能力與角色責任。 可先對照 Fuzz Test。

可觀察訊號與例子

系統需要 function-level authorization 的訊號是同一資源上有高風險操作。客服可以查看訂單，但退款、補發點數、修改收件資訊需要額外權限與 audit。

設計責任

授權設計要把 action 納入 policy，例如 order.read、order.refund、user.export。測試要覆蓋低權限使用者直接呼叫高風險 endpoint 的情境。

概念位置

Tenant boundary 是 authorization、data partition、rate limit、audit 與 billing 的共同邊界。它可以落在資料庫欄位、schema、database、queue、cache key、storage path 或 network policy。 可先對照 Throughput。

可觀察訊號與例子

系統需要 tenant boundary 的訊號是同一服務處理多個企業或組織。A 公司管理員只能看到 A 公司訂單；A 公司的大量匯出也應使用自己的查詢配額，保留 B 公司的正常容量。

設計責任

Tenant boundary 要在 query、cache key、message、log、audit、rate limit 與測試中保持一致。測試要覆蓋跨 tenant IDOR、資料匯出與背景 job。

概念位置

Least privilege 是權限模型與事故限縮工具。權限越大，credential 洩漏、程式 bug 或人為操作的影響範圍越大。 可先對照 Load Balancer Contract。

可觀察訊號與例子

系統需要 least privilege 的訊號是多個服務共用同一把高權限 credential。報表服務只需要讀取訂單摘要時，應使用專門的唯讀資料庫帳號。

設計責任

權限設計要分角色、分服務、分環境、分資源。Runbook 應包含權限審查、credential rotation、撤銷流程與異常操作 audit。

概念位置

IAM 位在 authentication、authorization 與組織治理之間。它常與 authentication、authorization 與 least privilege 一起出現，也會影響 tenant boundary 與 service account 管理。

可觀察訊號與例子

系統需要 IAM 的訊號是團隊、產品或租戶數量增加，且權限規則開始無法靠單一 application hard-code 維護。企業 SaaS、內部管理後台與雲端資源操作通常都需要 IAM 來統一角色與 policy。

設計責任

IAM 設計要定義身分來源、角色模型、權限授予、撤銷流程與稽核記錄。實作時要避免把高風險權限散落在各個 service，否則會讓權限審查、換人與事故處置變得困難。

概念位置

Security misconfiguration 是部署與操作層面的安全風險。程式邏輯正確仍可能因環境設定、預設值或部署流程錯誤而暴露資料或功能。 可先對照 Release Gate。

可觀察訊號與例子

系統需要設定檢查的訊號是服務有多個環境、公開入口或雲端資源。Debug endpoint 在 staging 可用，但若同設定進 production，可能暴露 runtime、config 或內部資料。

設計責任

防護要包含 baseline config、環境差異審查、secret scan、IaC review、security test 與 drift detection。高風險設定應進入 Release Gate。

概念位置

Input validation 是 API 邊界與安全邊界的第一層。它不取代 authorization、business rule 或 database constraint，但能提早拒絕無效資料並產生清楚錯誤。 可先對照 Internal Endpoint。

可觀察訊號與例子

系統需要 input validation 的訊號是 API 接收 JSON、檔案、URL、查詢條件或 webhook payload。日期範圍、email 格式、檔案大小、enum 值與 ID 格式都應在入口被驗證。

設計責任

Validation 要分層：格式檢查在入口，業務規則在 usecase，資料完整性由 database constraint 保底。錯誤回應要清楚但避免洩漏內部細節。

概念位置

WAF 位在流量入口與 application 之間。它適合處理 SQL injection、XSS、惡意 bot、異常 payload、重放型濫用與明顯不符合路徑語意的 request。 可先對照 Admin Endpoint。

可觀察訊號與例子

系統需要 WAF 的訊號是攻擊流量、濫用流量或掃描流量開始增加。公開 API、Admin Endpoint、file upload 與 webhook 入口如果暴露在網際網路上，通常需要額外的 WAF 規則與例外管理。

設計責任

WAF 設計要定義規則更新、誤殺處理、觀測指標、例外放行與回應流程。它不應取代 application 層的輸入驗證、授權或速率限制，而是作為第一層防護與風險降噪。

概念位置

SSRF 是伺服器端輸入驗證與網路出口控制問題。它常出現在 webhook 測試、圖片抓取、URL preview、匯入工具、PDF 產生與代理服務。 可先對照 Stakeholder Mapping。

可觀察訊號與例子

系統需要 SSRF 防護的訊號是使用者可以控制後端要連到的 URL。圖片上傳功能若支援「貼 URL 匯入」，後端必須限制可連線網域、IP range、scheme 與 redirect。

設計責任

防護要包含 allowlist、DNS/IP 檢查、禁止內網位址、限制 redirect、timeout、response size limit 與 egress policy。Log 要記錄目標 host 與拒絕原因。

概念位置

Attack surface 是紅隊分析的起點。它回答「哪裡先被看到」，因此會和 Public API、Admin Endpoint、Diagnostic Endpoint、Internal Endpoint、webhook 與 Security Misconfiguration 一起被檢查。

可觀察訊號與例子

系統只要有多種入口、不同權限等級、可枚舉資源或可回傳診斷資訊，就需要明確盤點 attack surface。若某個 endpoint 可以被猜路徑、透過錯誤訊息推回內部結構，或因預設設定而暴露額外能力，這個 surface 就應該被優先標記。

設計責任

暴露面管理要把入口用途、來源限制、資料回應與日誌責任分開定義。對外公開的 surface 需要比內部 surface 更嚴格的驗證、速率控制與回應最小化。

概念位置

PII 是 data classification、data masking、權限、retention、audit log 與資料匯出的核心分類。資料是否為 PII 會直接改變系統的存取控制與操作成本。

可觀察訊號與例子

系統需要 PII 分級的訊號是服務保存會員、訂單、付款、客服或行為資料。客服查詢電話需要遮罩；資料匯出需要核准與 audit log；log 應控制 PII 欄位。

設計責任

PII 設計要標出欄位分類、存取角色、遮罩規則、保留期限、匯出流程與刪除流程。測試資料也需要匿名化或合成資料策略，並和 secret management 分開管理。

概念位置

Trust boundary 會出現在 authentication、authorization、tenant boundary、TLS / mTLS、SSRF 與 network policy 交界。它是描述「哪裡開始需要重新驗證」的分析框架，涵蓋範圍超過任何單一防護措施。

可觀察訊號與例子

一個系統只要跨越 client、service、queue、storage、tenant 或第三方整合，就會產生 trust boundary。當邊界跨得越多，紅隊越會檢查訊號是否真的有被重新驗證，而不是延用前一段的假設。

設計責任

邊界管理要能說清楚誰信任誰、信任到哪裡、何時失效。若某段流程會跨越身份、租戶、網路或資料層邊界，就要在那一點重新定義驗證、授權與完整性檢查。

概念位置

資料分級是資安設計的上游。Authorization、data masking、TLS、secret management、audit log、retention 與 backup policy 都需要依資料等級調整。 可先對照 Data Completeness。

可觀察訊號與例子

系統需要 data classification 的訊號是同一服務處理多種風險資料。商品名稱可能是公開資料，使用者地址是 PII，付款 token 是高敏感資料，管理員操作紀錄是 audit 資料。

設計責任

資料分級要落到欄位、表、事件、log、匯出與測試資料。每個等級應定義存取條件、遮罩、加密、保留期限、audit 與事故處理要求。

概念位置

Abuse case 會落在 authentication、authorization、BOLA / IDOR、Function-Level Authorization、Least Privilege 與 Tenant Boundary 的交界。常見場景包含 export、invite、reset、approval、trial、switch、share 與 automation。

可觀察訊號與例子

如果一個功能有很多例外分支、角色切換或長流程，紅隊就會把它視為可濫用面。像是匯出功能被用來批量蒐集資料、邀請流程被用來擴張不該有的存取、重設流程被用來接管帳號，這些都是 abuse case。

設計責任

防護要能回答三件事：正常目的為何、可能被怎麼濫用、濫用時要在哪一層攔下來。若流程本身包含權限跳轉、狀態切換或代理操作，這些地方就應該優先被列為 abuse case。

概念位置

In-process channel 屬於 application 內部協調機制。Broker 跨 process 保存與投遞訊息；in-process channel 只在目前 process 存活期間承擔資料傳遞與 backpressure。

可觀察訊號與例子

系統需要 in-process channel 的訊號是同一個服務內部有 producer 與 worker 需要解耦。HTTP handler 接到工作後，可以先放進本地 queue，由 worker pool 處理；process 重啟後，尚未處理的本地工作通常會消失。

設計責任

In-process channel 要定義 buffer 大小、阻塞行為、關閉流程、drop policy、shutdown 與觀測欄位。需要跨 process 保存、重試或 replay 的工作應升級到 broker 或 durable queue。

概念位置

Service Endpoint 位在 client、load balancer、WAF 與 application 之間，是服務對外暴露能力的入口界面，常與 Request Routing 一起決定流量如何進入。

可觀察訊號

系統需要 service endpoint 分級的訊號是不同入口承擔的風險不同。公開 API、管理入口、診斷入口與內部入口的流量來源、權限要求與失敗後果都不一樣。

接近真實網路服務的例子

公開 API 需要穩定的 request/response 合約；Public API Endpoint 需要更高的相容性與文件品質；Admin Endpoint 需要更高權限與來源限制；Diagnostic Endpoint 需要避免暴露過多內部資訊；Internal Endpoint 需要搭配 service discovery 與內部網路邊界。

設計責任

設計時要先定義 service endpoint 的用途、可達範圍、授權層級與錯誤回應策略。更細的入口語意應拆成專門卡片，而不是把所有 HTTP 路徑都當成同一種入口。

概念位置

Worker pool 是 application 內部的容量控制工具。它常和 in-process channel、queue depth、backpressure、bulkhead、dependency isolation 與 graceful shutdown 一起使用。

可觀察訊號與例子

系統需要 worker pool 的訊號是工作可以排隊，但同時執行量需要受控。圖片縮圖、匯出報表、外部 API 同步與 webhook retry 都可以用 worker pool 限制 CPU、連線或下游 API 壓力。

設計責任

Worker pool 要定義 worker 數量、queue 長度、等待期限、錯誤回報、shutdown、重試與觀測欄位。擴大 worker 數前要先確認瓶頸位置：可能在 connection pool、HTTP client pool 或外部 API quota。

概念位置

Communication Protocol 位在 application、client、broker、API Gateway 或 service 之間，決定兩端如何交換資料與解讀狀態。

可觀察訊號

系統需要 communication protocol 明確化的訊號是多個元件開始共用同一種資料交換方式。若格式不穩定，錯誤就會出現在解析、版本相容、重試語意或欄位命名上。

接近真實網路服務的例子

請求/回應型通訊、queue message schema、webhook payload 與簽章驗證，都屬於 communication protocol 問題。這類約定需要被拆到更具體的子卡，才能維持原子性。

設計責任

設計時要定義版本相容、錯誤處理、欄位演進與測試方式。Communication Protocol 的目標是讓雙方知道哪些行為是約定的一部分，格式複雜度應盡量收斂。

概念位置

HTTP client 是常見下游依賴入口。它可能呼叫付款、通知、搜尋、身份驗證、第三方 API 或內部微服務；每個 client 都會把外部延遲與失敗帶回 application。 可先對照 Timeout。

可觀察訊號與例子

系統需要整理 HTTP client 的訊號是下游 API 變慢後，上游 request latency 與 worker 等待同步上升。付款 API timeout 時，checkout 要能快速分類錯誤、限制重試並保留使用者流程。

設計責任

HTTP client 要定義連線池、timeout、retry budget、backoff、jitter、circuit breaker、authentication、TLS 與 log / metrics / trace 欄位。不同下游應有獨立設定與觀測名稱。

概念位置

Container 位在 build、deploy、runtime 與 platform 之間，是服務交付與資源限制的基本單位。 可先對照 Resource Limit。

可觀察訊號

系統需要 container 化的訊號是服務需要一致的啟動方式、相同的 runtime 環境、可複製的部署流程，或多個 instance 要共用同一套交付模型。

接近真實網路服務的例子

當服務要被放進 Kubernetes、CI pipeline 或 VM 上的標準化部署流程時，container 可以把 binary、system dependency 與啟動參數打包成固定形狀，降低環境差異。

設計責任

設計時要定義 image 內容、啟動命令、resource limit 與環境變數來源。Container 是讓服務交付、擴容與回滾更一致的手段，目的在服務層面。

概念位置

Stream pipeline 常出現在 event stream、log processing、CDC、ETL、即時分析、IoT readings 與訊息轉換流程。它需要處理 ordering、partition、checkpoint、backpressure、retry 與資料完整性。

可觀察訊號與例子

系統需要 stream pipeline 設計的訊號是資料會持續進入，且需要多步驟加工。訂單事件先做清洗，再寫入搜尋索引與報表系統；任一階段變慢，都會讓上游 lag 擴大。

設計責任

Stream pipeline 要定義階段邊界、buffer、checkpoint、錯誤隔離、重放、lag 指標與 correctness check。每個階段都要能被單獨觀測與限速。

概念位置

Buffer 是平滑尖峰的工具，也是延遲與記憶體風險來源。Buffer 太小會讓 producer 很快被阻塞或拒絕；buffer 太大會累積延遲、記憶體壓力與過期工作。

可觀察訊號與例子

系統需要 buffer 設計的訊號是流量有短暫 burst，但下游平均容量足夠。通知服務可以用小型 buffer 吸收幾秒尖峰；長時間進入速度高於處理速度時，buffer 只會把問題延後。

設計責任

Buffer 要定義容量、等待期限、溢出策略、drop policy、觀測欄位與 shutdown 行為。觀測上要看 fill ratio、oldest item age、drop count 與處理耗時。

概念位置

Load balancer 位在 client 與 application instances 之間，是服務接流量與停止接流量的入口控制層，常與 Request Routing 搭配使用。

可觀察訊號

系統需要 load balancer 的訊號是服務有多個 instance、要做 rolling update、需要平滑擴容，或必須在故障時把流量移開。

接近真實網路服務的例子

Kubernetes service、edge proxy、API Gateway 或雲端 LB 都會把 request 導到健康節點。長連線服務也常依賴 load balancer 做 draining，避免關閉中的 instance 繼續接新流量，也會透過 idle timeout 回收空閒連線。

設計責任

設計時要定義健康條件、移除條件、回切條件與排空時間。Load balancer 本身不處理業務邏輯，但它直接影響可用性、切換速度與連線體驗。

概念位置

Queue 可以存在於 application 內部（in-process channel + worker pool），也可以由 broker、database table 或 stream platform 提供。Application 內部的 queue 隨 process 生命週期消失；跨 process、需要保存與重放的 queue 通常需要 durable queue 或 broker。

Queue 跟 topic 的差異：queue 的語意通常是「一筆訊息被一個 consumer 處理」（competing consumers），topic 的語意是「一筆訊息可以被多個 consumer group 各自處理」（fan-out）。但不同 broker 的術語定義不同 — RabbitMQ 的 queue 跟 Kafka 的 partition 在消費語意上有本質差異。

使用情境

系統需要 queue 的訊號是進入速度跟處理速度會短暫不一致。寄信、報表匯出、圖片轉檔、訂單狀態同步都適合先排入 queue，再由 consumer 依照容量處理。Queue depth 跟 oldest item age 會反映延遲壓力 — queue depth 持續增長代表 consumer 來不及消化，需要擴展 consumer 或降低進入速率。

設計責任

Queue 要定義容量上限、排序語意（FIFO / priority / delay）、保存期限（retention）、消費模式（pull vs push）、失敗處理（retry policy + dead-letter queue）、backpressure 策略（滿了怎麼辦 — block / drop / reject）與觀測欄位。設計上要區分「等待可以接受」跟「等待會傷害產品結果」— 付款入帳能短暫排隊，互動式 API response 通常需要更短的等待期限與更明確的拒絕策略。

概念位置

Sticky Session 位在 client、load balancer、application instances 與 session state 之間。它改變的是流量分派規則，不是應用邏輯本身。 可先對照 Stream Pipeline。

可觀察訊號

系統需要 sticky session 的訊號是：

• 服務仍保存本機狀態，短期內不容易外部化
• 多步驟互動需要維持同一個後端實例
• session state 還沒移到共享儲存或快取

接近真實網路服務的例子

聊天室、即時遊戲、某些登入流程、需要本機暫存的舊系統，常會要求同一個使用者在 session 期間保持 sticky routing。

設計責任

設計時要定義黏著的判斷鍵、有效時間、失效後怎麼重新導向、以及單一 instance 故障時如何處理 session 遷移。Sticky Session 會讓負載分佈變得不均，因此要清楚知道它是權宜策略，不是預設最佳解。

概念位置

Probe 位在 platform 與 application 之間，讓調度系統知道 instance 是否可接流量、是否仍存活，或是否仍在啟動中。 可先對照 Producer。

可觀察訊號

系統需要 probe 的訊號是啟動、擴容、故障、健康檢查與回收流程需要自動化判斷。沒有 probe，平台只能用硬編碼規則猜測服務狀態。

接近真實網路服務的例子

Kubernetes 會用 probe 決定 instance 是否加入流量池。Readiness probe 檢查能否接流量；liveness probe 檢查 process 是否卡死；startup probe 則可保護啟動較慢的服務。

設計責任

設計時要讓 probe 簡單、快速、穩定，並且只反映它自己的責任範圍。Probe 不應該做昂貴查詢或深度業務判斷，否則平台訊號會不穩定。

概念位置

Startup probe 位在 container 啟動與 readiness / liveness 之間。startup probe 成功前，liveness 和 readiness 不會啟動。startup probe 一旦成功就永久停用，由 liveness 和 readiness 接手。可先對照 Graceful Shutdown。

可觀察訊號

系統需要 startup probe 的訊號是「服務啟動時間超過 liveness 的預設容忍窗口」。典型場景：JVM 服務 warmup 需 30-60 秒、依賴多的服務需要等資料庫連線池和 cache 連線建立。沒有 startup probe 時，liveness 會在初始化期間把健康的服務判定為壞掉，觸發 restart loop。

設計責任

startup probe 的總容忍時間 = failureThreshold × periodSeconds。設計時先量測服務在最差情境下的啟動時間（冷啟動 + image pull + 依賴連線），再加 headroom。startup probe 跟 initialDelaySeconds 解決同一個問題，但 startup probe 在啟動期間持續探測（能偵測啟動失敗），initialDelaySeconds 是盲等（無法觀測啟動進度）。

概念位置

API Gateway 位在 client 與多個 backend service 之間，通常介於 load balancer 和 application 之間，作為外部入口的統一控制點，並常與 Request Routing 一起決定流量要導向哪個後端。

可觀察訊號

系統需要 API Gateway 的訊號是：

• 多個服務共享同一個對外入口
• 想把 auth、rate limit、request id、Request Routing 集中處理
• 希望在不改每個 service 的情況下調整入口行為

接近真實網路服務的例子

公共 API、行動 app、合作夥伴整合或多租戶入口常會先經過 API Gateway，再導向對應 service、internal endpoint 或特定版本路由。

設計責任

設計時要明確定義 gateway 能做與不能做的事。它應承擔流量入口治理，而不應塞入核心業務邏輯，否則會變成難以維護的分散型控制層。

概念位置

Draining 位在 load balancer、deployment platform、application 與 in-flight work 之間。它介於流量入口與工作完成之間，目標是避免切換瞬間把正在處理的請求硬切掉。 可先對照 Dual Write。

可觀察訊號

系統需要 draining 的訊號是：

• instance 要下線或被替換
• 長連線或背景工作不能被直接中斷
• 切流時需要避免新請求進入舊實例

接近真實網路服務的例子

Kubernetes rolling update 前先讓 instance 進入 draining、load balancer 在切流前停止導入新連線、worker 停止接收新 job 但完成目前處理，都是 draining 的應用。

設計責任

設計時要定義何時開始 draining、draining 多久、超時後怎麼強制終止，以及如何觀察 in-flight request、consumer ack 與長連線狀態。Draining 的目的是把切換風險壓到可接受範圍，無限等待反而製造新風險。

概念位置

Socket 位在 application runtime、作業系統與網路之間。上層通常看到的是 HTTP client、database client 或 broker client；底層則由 socket 負責連線、讀取、寫入與關閉。

可觀察訊號與例子

系統需要理解 socket 的訊號是外部依賴變慢時，application 的連線數、等待時間與資源使用同步上升。付款 API response 變慢時，HTTP client 可能佔住更多 socket；如果 timeout 太長，worker 會把時間花在等待網路回應。

設計責任

Socket 相關設計要定義連線數上限、read / write timeout、idle timeout、connection pool、buffer 大小與關閉流程。操作上要觀察連線數、timeout、reset、重連次數與下游 latency，避免網路等待耗盡 application 的 worker 或檔案描述符。

概念位置

Idle Timeout 位在 socket、load balancer、proxy、application 與 connection pool 之間。它常用來保護連線資源，避免長時間閒置造成檔案描述符、memory 或 session state 浪費。 可先對照 Impact Scope。

可觀察訊號

系統需要 idle timeout 的訊號是：

• 長連線長時間沒有資料交換
• 空閒連線數量持續累積
• load balancer 或 proxy 需要回收無效連線

接近真實網路服務的例子

WebSocket 連線、HTTP keep-alive、反向代理連線池或 application 內部 socket pool，常會透過 idle timeout 回收不再使用的連線。

設計責任

設計時要定義閒置判定條件、關閉前通知、重連策略與是否允許不同層級使用不同 timeout。Idle Timeout 應該和 read/write timeout、request timeout 區分開來，避免把不同問題混在一起。

概念位置

Request Routing 位在 client、API Gateway、Load Balancer 與 application 之間。它通常依 host、path、header、method、tenant、版本或地區決定流量走向。

可觀察訊號

系統需要 request routing 的訊號是：

• 同一個對外入口要支援多個服務或版本
• 不同路徑需要不同安全政策、觀測欄位或後端處理
• 需要在不改 client 的情況下調整入口分派

接近真實網路服務的例子

/api/v1 與 /api/v2 導向不同版本服務、依 tenant 送到不同區域、依 path 導向不同內部服務，或把健康流量從一組 instance 切到另一組，都屬於 request routing。

設計責任

設計時要定義匹配條件、優先順序、預設路徑與回復方式。Request Routing 本身不應承擔業務邏輯，只應負責把入口流量穩定送到正確目標。

概念位置

Producer 位在資料流的上游。它的送入速度、資料品質與錯誤處理會直接影響 consumer、queue depth、backpressure 與下游成本。

可觀察訊號與例子

系統需要辨識 producer 的訊號是同一個處理路徑有多個資料來源。訂單建立 API、批次匯入工具與第三方 webhook 都可能產生訂單事件；如果每個 producer 的資料格式與重試策略不同，consumer 會承擔更多判斷成本。

設計責任

Producer 要定義送入條件、資料格式、唯一識別碼、idempotency、retry policy、rate limit 與觀測欄位。操作上要能按 producer 來源查看進入速率、錯誤率、payload 大小與被拒絕數量，才能在尖峰或資料異常時定位來源。

概念位置

WebSocket 位在 application 與網路連線之間，常用於聊天、協作編輯、presence、即時通知與 dashboard 更新。它和 socket 不同的是，WebSocket 是上層通訊協定與互動模式，而 socket 是底層連線抽象。

可觀察訊號與例子

系統需要 WebSocket 的訊號是 client 需要持續收到變化，且單純 request / response 太慢或太重。多人聊天室、即時客服、任務進度與連線狀態同步都常見 WebSocket。

設計責任

WebSocket 設計要定義連線生命週期、heartbeat、reconnect、訊息順序、disconnect 處理與 offline catch-up。若訊息不能遺失，通常還要搭配 pub/sub、持久化資料或補送流程。

概念位置

Consumer 位在資料流的下游。它跟 producer 構成 MQ 的基本角色對 — producer 負責把工作送進等待區，consumer 負責取出並處理。

多個 consumer 組成 consumer group 來分攤處理負載。Consumer 的處理速度跟錯誤行為直接影響 consumer lag（積壓深度）跟 dead-letter queue（無法處理的訊息去處）。

使用情境

系統需要辨識 consumer 的訊號是資料已經送入系統但產品結果還沒完成。付款事件送入後，入帳 consumer 要更新帳務狀態；通知事件送入後，寄信 consumer 要呼叫郵件服務。兩者都要清楚記錄處理成功、暫時失敗與永久拒絕。

Consumer 的處理模式影響系統的可靠性保證。Ack / nack 的時機決定「訊息什麼時候算處理完成」；idempotency 決定「重複收到同一筆訊息時是否會產生副作用」。

設計責任

Consumer 要定義併發數、ack / nack 條件、錯誤分類（暫時性 vs 永久性）、idempotency、retry policy、隔離區、graceful shutdown 與觀測欄位。

操作面要能觀測：處理速率（messages/sec）、失敗類型分布、oldest unprocessed message age、consumer lag、dead-letter queue 累積量與下游 dependency latency。Consumer lag 持續增長是容量不足的 leading indicator。

概念位置

Health Check 位在 load balancer、platform、diagnostic endpoint 與 application 之間。平台會依這個回應決定是否導流、是否重啟，或是否需要進一步檢查。 可先對照 Histogram。

可觀察訊號

系統需要 health check 的訊號是服務需要一個快速、低成本、可自動化的狀態回應，讓平台不用靠猜測判斷是否正常。

接近真實網路服務的例子

Load balancer 以 health check 判斷 instance 能否接新流量；運維工具以 health check 快速確認服務是否仍回應；Kubernetes 會把 health check 的責任拆到 readiness / liveness / startup probe。

設計責任

設計時要讓 health check 保持簡單、穩定、低成本，並且只反映它被設計要回答的問題。更細的流量條件交給 readiness，更細的存活條件交給 liveness，更完整的操作介面交給 diagnostic endpoint。

概念位置

SSE 位在 HTTP 之上，適合 server 主導的事件串流。它常用於通知、進度更新、系統訊號與簡化版即時 feed。 可先對照 Offline Catch-up。

可觀察訊號與例子

系統需要 SSE 的訊號是 client 只需要接收事件、不需要頻繁回傳雙向互動。活動進度條、批次作業狀態、公告 feed 與監控看板更新都可能使用 SSE。

設計責任

SSE 設計要定義斷線重連、事件 ID、補送起點與保留窗口。若 client 離線後仍要完整補回資料，仍要搭配 offline catch-up 或正式儲存路徑。

概念位置

Topic 是事件分流的命名邊界。它讓訂單、付款、會員、通知、庫存等事件可以被不同服務訂閱，也讓團隊用事件種類思考資料流與責任範圍。

Topic 跟 partition 的關係是：topic 是邏輯命名空間，partition 是 topic 內的物理分片。Topic 跟 fan-out 的關係是：多個 consumer group 訂閱同一個 topic，每個 group 各自消費全量事件，實現 fan-out。

在 RabbitMQ 生態中，topic 對應 exchange + routing key 的組合；在 NATS 中 topic 對應 subject。概念相同但術語跟語意細節不同。

使用情境

系統需要 topic 設計的訊號是同一個事件來源會供多個 downstream 使用。付款完成事件可以給出貨、通知、報表與風控使用；所有事件都混在同一條 queue 時，consumer 會承擔更多過濾與相容性成本。

Topic 命名規則影響長期治理。orders.payment.completed 比 event_1 更容易被搜尋跟管理。命名規則要在團隊間統一、進 queue contract 管理。

設計責任

Topic 設計要定義命名規則、事件 schema、相容性策略（schema evolution）、權限控制（誰能 publish / subscribe）、retention 期限、replay runbook 範圍與 ownership（哪個團隊負責這個 topic）。操作面要能依 topic 查看 publish rate、consumer lag、錯誤率與 dead-letter queue 數量。

概念位置

Resource Limit 位在 container、runtime、deployment platform 與 scheduler 之間。它決定服務在資源不足時是被 throttling、被拒絕排程，還是因記憶體超限而被終止。 可先對照 Retention。

可觀察訊號

系統需要 resource limit 的訊號是：

• 多個 instance 需要共享固定主機資源
• 單一服務可能因記憶體成長或 CPU 尖峰影響其他服務
• 平台需要用上限保護整體節點穩定性

接近真實網路服務的例子

Kubernetes container limit、單機 systemd service 的 cgroup 限制、worker pool 的 CPU 上限或 memory cap，都屬於 resource limit 的問題。

設計責任

設計時要區分 request 與 limit、理解 throttling 與 OOM 的差異，並把上限調整和實際流量、cache、啟動成本與重試行為一起看。Resource Limit 的目標是保護系統穩定，而不是只追求把數字填滿。

概念位置

Routing rule 是 broker 內的分流邏輯。它把 producer 的輸出轉成不同 queue、consumer group 或 stream partition，讓不同工作可以用不同容量、權限與 retry policy 處理。

可觀察訊號與例子

系統需要 routing rule 的訊號是同一類事件有不同處理代價。一般通知可以進入低成本 queue，高價值訂單通知可以進入優先 queue；退款事件可以交給需要更完整 audit log 的 consumer。

設計責任

Routing rule 要有可測試規則、預設路徑、觀測欄位與變更流程。規則錯誤會讓訊息進錯 queue、漏處理或造成局部 consumer lag，因此每次調整都要搭配樣本驗證與回復方式。

概念位置

Database 是產品狀態與操作證據的核心依賴。Cache、search index、read replica、event stream 與報表通常都是衍生資料；資料衝突時，團隊需要知道哪個 database 或資料表承擔正式判斷。 可先對照 Source of Truth。

可觀察訊號與例子

系統需要 database 設計的訊號是資料要被長期保存、查詢、修改與稽核。訂單服務需要保存訂單狀態、付款紀錄、出貨狀態與取消原因；這些資料會影響客服、帳務、出貨與報表。

設計責任

Database 設計要包含 schema migration、transaction boundary、isolation level、connection pool、備份回復、權限、資料保留與觀測指標。操作上要能看 query latency、lock、replication lag、connection pool 使用量與錯誤分類。

概念位置

Transaction 是正式資料一致性的工具。它適合保護同一個 database 內的狀態變更，例如建立訂單、扣庫存、寫入付款紀錄；跨服務通知、外部 API 與 broker publish 則需要 outbox pattern、補償或 data reconciliation。

可觀察訊號與例子

系統需要 transaction 的訊號是半完成狀態會造成產品錯誤。付款紀錄建立成功但訂單仍停在未付款，客服、倉儲與帳務會看到衝突資料；transaction 可以把這些同庫變更合併成同一個成功條件。

設計責任

Transaction 設計要控制範圍、時間、鎖、retry policy、timeout 與錯誤分類。長 transaction 會增加 lock 與 connection pool 壓力，因此應把外部呼叫與長時間工作移出交易範圍。

概念位置

Migration 是 release、資料一致性與操作風險的交界。它通常需要同時考慮相容性、觀測、回復、cutover / switchover、fallback plan 與 correctness check。

可觀察訊號與例子

系統需要 migration 設計的訊號是新舊路徑會並存一段時間。電商把搜尋從舊索引切到新索引時，需要 shadow read 比對結果、backfill 既有商品、觀察錯誤率，最後再切正式流量。

設計責任

Migration 要定義階段、擁有者、資料範圍、驗證方式、回復條件與完成標準。高風險 migration 應把資料變更、application release 與流量切換拆成可觀察、可停止的步驟，並在上線前安排 Rollback Rehearsal 與 Migration Gate。

概念位置

Expand / Contract 位在 schema migration、online migration、deployment 與 release gate 之間。它是降低變更風險的遷移順序，不是單一工具。 可先對照 Exponential Backoff。

可觀察訊號

系統需要 expand / contract 的訊號是：

• 舊版本與新版本會同時存在
• 新功能需要先讓舊程式不壞掉
• 移除舊欄位或舊路徑前，必須先讓新版本穩定接上
• migration 不能一次做完

接近真實網路服務的例子

新增欄位時先擴表、補預設值、讓新舊版本都能讀寫，再等舊版本完全退出後移除舊欄位；換搜尋索引時先讓新寫入同步到兩邊，等驗證完成後再收斂舊索引。這些都屬於 expand / contract。

設計責任

Expand / Contract 要定義擴張階段、相容條件、收斂條件、驗證方式與回復方式。它的重點是讓每一步都保有回頭路。

概念位置

Log 是可觀測性的事件明細層。Metrics 負責趨勢，trace 負責跨服務路徑，log 負責提供單一事件的判斷證據；log schema 則讓這些紀錄可以被穩定搜尋與聚合。

可觀察訊號與例子

系統需要 log 設計的訊號是事故時需要回答「哪一筆資料在哪一步失敗」。Checkout 失敗時，團隊需要用 request id、order id、payment id 與錯誤分類找出同一流程的所有紀錄。

設計責任

Log 設計要定義 log level、事件名稱、欄位、錯誤分類、敏感資料遮罩、retention 與查詢成本。高風險操作應另外寫入 audit log，保留責任證據。

概念位置

可靠性邊界通常出現在 request 結束點、跨 process 傳遞點、跨服務傳遞點與外部第三方呼叫點。邊界內可依靠 transaction、持久化與 ack 機制；邊界外需要 offline catch-up、replay runbook 與 idempotency 補償。

可觀察訊號與例子

系統需要明確 reliability boundary 的訊號是「同一筆事件在某些路徑可追蹤，在某些路徑不可追蹤」。例如聊天推播可接受短暫遺失，但付款通知需要補送；這代表兩者的可靠性邊界不同。

設計責任

設計時要定義哪類事件屬於 strong reliability、哪類事件可用低成本即時通道，並對每類事件提供對應的回復與驗證流程。

概念位置

Trace 是跨服務診斷的路徑層，跟 log（事件層）和 metrics（趨勢層）互補。Log 回答「某個服務發生了什麼」；metrics 回答「服務的健康趨勢」；trace 回答「一次 request 跨服務時，時間花在哪、錯誤發生在哪一段」。

Trace 在 waterfall view 中呈現為時間軸上的巢狀條狀圖，root span 在最上面、child span 依序往下。診斷價值是一眼看出延遲瓶頸 — checkout 總延遲 800ms 中 payment span 佔 600ms，問題定位立刻縮小範圍。

使用情境

系統需要 trace 的訊號是單一服務的 log 只呈現局部。Checkout 變慢時，trace 可以顯示時間主要花在庫存查詢、付款 API、database lock 或通知 worker。跨服務錯誤（upstream 回 500 但不知道是哪個 downstream 引起的）也依賴 trace 定位。

Trace 聚合後可以自動生成 service topology — 哪些服務在呼叫哪些服務、call 頻率、延遲分布、錯誤率。這個 graph 反映實際流量而非設計文件。

設計責任

Trace 設計要處理 trace context 傳遞（HTTP header、queue message header、thread context）、sampling 策略（head / tail / adaptive）、span 命名慣例、敏感資料 redaction、跨語言 SDK 相容性與 log correlation（trace id 寫進 log 欄位）。

高流量服務需要控制採樣成本，同時保留錯誤與高延遲樣本。Sampling 策略的完整討論見 4.7。Context propagation 在不同邊界（HTTP / queue / thread pool / background job）的斷鏈風險與修復見 4.3。

概念位置

Migration Gate 位在 migration、backfill、correctness check、data completeness 與 cutover 之間。它是遷移內部的階段控制點，不等於一般的 release gate。 可先對照 Migration。

可觀察訊號

系統需要 migration gate 的訊號是：

• 新舊狀態會並存一段時間
• 進下一階段前要先確認資料已補齊或結果已比對
• 切換前必須先確認副作用可控
• 遷移失敗時要能停在安全階段

接近真實網路服務的例子

資料搬遷到新 table 後，先確認 row count、關聯完整性與抽樣結果，再決定能否進入 cutover；搜尋索引重建完成後，先通過 correctness check 與 shadow read，再把讀取流量切過去。這些決定都屬於 migration gate。

設計責任

Migration Gate 要定義每一階段的通過條件、資料證據、擁有者與停止條件。它的目標是讓遷移不只是「做完」，而是「安全地前進或回頭」。

概念位置

Pub/Sub 常用在即時通知、presence 變更、前端狀態廣播與跨節點訊號同步。它和 durable queue 的差異在於：pub/sub 偏即時分發，durable queue 偏可靠處理。

可觀察訊號與例子

當需求是「在線訂閱者盡快收到訊息」時，pub/sub 是常見候選。例如聊天室 typing indicator、任務進度更新、dashboard 即時刷新。若訂閱者離線後仍要補送，通常需要搭配 offline catch-up 或 durable storage。

設計責任

設計時要明確訊息是否可遺失、是否需要持久化、是否需要重播。若需求轉向高可靠，應把關鍵事件切到 strong reliability 路徑。

概念位置

Dashboard 是告警與排障之間的判讀層。Alert 告訴團隊需要注意，dashboard 幫團隊判斷影響範圍、變化趨勢與可能原因，runbook 則把判讀結果轉成處理步驟。

Dashboard 分層服務不同使用者：service overview 給 on-call 工程師、debug dashboard 給事故中的深入診斷、capacity dashboard 給容量規劃。把所有資訊擠在同一個 dashboard 會讓每個角色都找不到自己要的。

使用情境

系統需要 dashboard 的訊號是事故中需要快速回答「影響多大、從何時開始、哪個依賴異常」。Dashboard 也是日常巡檢的入口 — on-call 工程師每天先看 service overview 確認服務健康，再處理 alert queue。

設計責任

Dashboard 設計要服務具體決策。每個面板應對應一個可回答的問題（「服務現在健康嗎」「延遲瓶頸在哪」「容量還夠嗎」）。高 cardinality、缺少單位或只呈現低層資源的圖表會增加判讀成本而非降低。

Dashboard panel 的查詢效能影響使用體驗 — 長時間趨勢 panel 應讀 recording rule 或 rollup 資料，避免每次刷新都掃描 raw series。Dashboard / alert 的完整設計見 4.4。

概念位置

Fan-out 常搭配 pub/sub 模型、topic 跟 consumer group 實作。在 Kafka 中，多個 consumer group 訂閱同一個 topic 就是 fan-out — 每個 group 各自從 offset 0 開始消費。在 RabbitMQ 中，fanout exchange 把訊息複製到所有綁定的 queue。在 GCP Pub/Sub 中，多個 subscription 訂閱同一個 topic。

Fan-out 跟 fan-in（多個來源合併成一個流）是相反的拓撲。兩者可以組合成事件處理管線。

使用情境

order.paid 事件同時觸發出貨準備（物流服務）、交易通知（通知服務）、營收紀錄（報表服務）與風控評估（風控服務）。Producer 不需要知道有哪些 consumer — 加減 consumer 不影響 producer 的程式碼。

Fan-out 降低了 producer 跟 consumer 之間的耦合，但擴大了排障範圍 — 一筆事件的處理結果散落在多個 consumer，需要用 trace context 或 correlation id 串連。

設計責任

設計 fan-out 時要為每個訂閱者定義可靠性等級跟回復策略。通知服務短暫失敗可以 retry；報表服務落後可以批次追補；但出貨服務的失敗可能需要人工介入。把所有下游綁成同一個失敗域（一個 consumer 卡住就全部暫停）會讓 fan-out 的解耦價值消失。每個 consumer group 應該獨立管理 consumer lag、dead-letter queue 跟 replay runbook。

概念位置

Validation query 位在 schema migration、data reconciliation 與 evidence package 之間。Correctness check 定義要驗什麼，validation query 則把規則落成可查、可保存、可交接的證據。

可觀察訊號

系統需要 validation query 的訊號是：

• 新舊欄位或新舊資料模型會並存一段時間
• backfill job 顯示完成，但仍需要證明資料語意正確
• cutover 前要知道 mismatch 集中在哪些資料範圍
• 事故修復後要留下可回放的資料證據

接近真實網路服務的例子

訂單服務把 status 裡的付款語意拆到 payment_state 時，validation query 可以比對每批訂單的新舊語意、缺值筆數、mismatch sample 與 replication lag 對位。這些結果會進入 release gate，而不是只停在 migration job 的成功訊息。

設計責任

Validation query 要保留 query version、time range、資料範圍、mismatch 分類與 owner。它的目標是支援 rollback window 與 incident decision log 判讀，讓團隊能知道下一步是繼續、暫停、回退讀取，還是做資料修補。

概念位置

Alert 是可觀測性進入操作流程的入口。Symptom-based alert 優先偵測使用者可感知結果（error rate、latency p99）；cause-based alert 偵測內部原因（CPU、queue depth、connection pool）。Symptom-based 用於 page on-call、cause-based 用於 warning 級通知。

Alert 觸發後由 on-call 工程師承接，按 runbook 的步驟診斷跟處理。

使用情境

系統需要 alert 設計的訊號是服務異常需要在使用者大量回報前被發現跟處理。付款成功率下降、API availability 低於 SLO、consumer lag 持續擴大或 DLQ 快速增加，都應觸發可行動通知。

設計責任

Alert 設計要定義門檻、持續時間（for duration）、severity、通知對象、抑制規則、runbook link 與回復條件。每個 alert rule 帶 owner metadata — 沒有 owner 的 alert 會在服務演進後退化成 noise 來源，形成 alert fatigue。

SLO-based alerting 用 burn rate 取代固定閾值，自動適應流量變化。完整的 alert 設計見 4.4、SLO-based alerting 見 4.6。

概念位置

Read compatibility 位在 dual write、cutover / switchover 與 migration gate 之間。雙寫處理寫入一致性，read compatibility 處理讀取方如何在缺值、延遲回填或版本混跑時仍能給出一致判讀。

可觀察訊號

系統需要 read compatibility 的訊號是：

• 新欄位已新增，但歷史資料尚未全部 backfill
• 新舊程式版本會同時服務流量
• rollback 後舊版本仍需要讀懂 production 資料
• 內部後台、對帳或報表的切換節奏不同於使用者可見路徑

接近真實網路服務的例子

訂單服務新增 payment_state 後，讀取時可先看新欄位，缺值時回到舊 status 的付款語意。客服後台可以先用這條相容讀取路徑驗證資料，再逐步讓使用者可見查詢改用新欄位。

設計責任

Read compatibility 要定義讀取優先順序、fallback read 條件、資料新鮮度限制與停止條件。它要搭配 validation query 與 rollback strategy，避免 cutover 後才發現舊版本或長尾讀取路徑無法判讀資料。

概念位置

Offline catch-up 常出現在 WebSocket、mobile push 與跨區域同步。即時通道只負責在線時低延遲傳遞，離線後的完整性通常由 durable queue、event log 或資料庫狀態查詢提供。

可觀察訊號與例子

例如聊天訊息在使用者離線時不能遺失，重新上線後需要補拉缺失訊息；typing indicator 可以不補送。兩者差異來自事件語意，而不是傳輸通道本身。

設計責任

設計時要定義補送範圍、游標或版本、補送時限與去重規則，並把流程寫入 runbook。

概念位置

Runbook 是 alert 的行動指南。Alert 告訴 on-call 工程師有問題，runbook 告訴他們「收到這個 alert 時該做什麼」。每個 critical alert 應該連到一份 runbook — 缺少 runbook link 的 alert 等於「通知了但不告訴你做什麼」，是 alert fatigue 的起點。

Runbook 也服務於 post-incident review — 事故中實際執行的步驟跟 runbook 預設的步驟比較，差異就是 runbook 需要更新的地方。

使用情境

系統需要 runbook 的訊號是同一類事故每次都靠個人經驗處理。DLQ 快速增加時，runbook 應引導處理者查看錯誤分類、payload 範圍、最近部署、replay 條件與暫停 consumer 的判斷。

設計責任

Runbook 的有效結構：症狀描述、影響評估、診斷步驟（先看哪個 dashboard、查哪些 log）、可能的修復動作（restart / scale / rollback / failover）、升級路徑（15 分鐘內無法解決時通知誰）。維護責任跟 alert 的 owner 一致 — alert rule 改了但 runbook 沒更新是常見的退化。完整設計見 4.4。

概念位置

Fallback read 位在 cutover / switchover、schema migration 與 rollback strategy 之間。它保留新資料結構、暫時把讀取判斷交回舊語意或舊來源，比完整 rollback 成本低且破壞性小。

可觀察訊號

系統需要 fallback read 的訊號是：

• 新欄位讀取後 mismatch 升高
• 客服後台、報表或使用者可見查詢結果漂移
• 寫入路徑已經收斂，但讀取模型或索引尚未穩定
• release gate 允許暫停 cutover，但尚未需要資料修補

接近真實網路服務的例子

訂單服務把付款狀態拆到 payment_state 後，客服後台若發現新欄位判讀 mismatch 升高，可以先回到舊 status 的付款語意讀取，讓客服分類回到基線，同時保留 backfill 與 validation query 繼續查證。

設計責任

Fallback read 要定義觸發條件、讀取優先順序、可維持多久、哪些入口適用，以及何時重新嘗試 cutover。它要與 validation query 和 incident decision log 對齊，避免讀取回退變成沒有證據的永久分岔。

概念位置

高可靠路徑常用在金流、庫存、權限與稽核事件。這些路徑通常需要 message persistence、retry policy、idempotency、dead-letter queue 與回復流程。

可觀察訊號與例子

例如付款成功事件若遺失，可能造成對帳錯誤；這類事件需要保存與補送。相對地，typing indicator 遺失通常不影響核心產品承諾。

設計責任

設計時要定義失敗代價、保證等級、觀測指標與驗證流程，並界定 reliability boundary。

概念位置

Cutover window 位在 release gate、steady state 與 evidence package 之間。Release gate 決定能否開始切換，cutover window 定義切換後多久內要看哪些訊號、達到什麼條件才算穩定。

可觀察訊號

系統需要 cutover window 的訊號是：

• 新路徑開始承接正式讀取或寫入
• 切換後需要觀察 mismatch、latency、error rate 或 lag
• 回退條件只在切換初期仍然低成本
• 多個入口會分批切換，需要分別記錄時間窗

接近真實網路服務的例子

客服後台先切到新 payment_state 讀取後，前 30 分鐘是 cutover window。這段期間要看 mismatch sample、客服查詢慢查詢、對帳補償量與 rollback window；穩定後才放行使用者可見讀取。

設計責任

Cutover window 要定義開始時間、觀察長度、通過條件、stop condition 與 owner。它應進入 evidence package 與 incident decision log，讓事後能回放切換當時的訊號。

概念位置

Durable queue 是 queue 與 message persistence 的組合，常由 broker 提供，並搭配 ack/nack、retry policy 與 dead-letter queue。

可觀察訊號與例子

當工作可延遲但不可遺失時，durable queue 是常見候選。例如付款後通知、對帳同步、背景轉檔。若僅需在線即時廣播，通常 pub/sub 成本更低。

設計責任

設計時要定義保存期限、重試上限、去重策略、queue lag 告警與回復流程，避免把可靠性責任留給人工排障。

概念位置

Event log 是 event sourcing 的儲存層。在 event sourcing 架構中，event log 是 source of truth，current state 透過 replay 事件流推算。在非 event sourcing 架構中，event log 是輔助紀錄 — 正式狀態仍由 mutable record 承擔，event log 提供變更歷史跟 replay 能力。

Event log 的讀取面透過 projection 轉換成 read model，讓消費者不需要每次 replay 整條事件流。在訊息傳遞面，event log 常搭配 consumer group、offset 與 replay runbook 使用。

使用情境

訂單狀態變更可寫入 event log，後續由報表、通知、稽核服務各自消費。當下游落後時，可用 replay 補齊資料。金融帳務的每一筆增減、權限變更的每一次授權與撤銷、訂閱方案的每一次升降級，都是典型的 event log 應用。

設計責任

設計時要定義事件 schema 演進（新版 consumer 要能消費舊版事件）、保留期限（無限保留 vs retention-based 清理）、重播邊界（從哪個 offset 開始 replay）與去重策略（idempotency 保證）。Event log 的儲存成長是長期成本 — 高頻寫入的系統需要 snapshot 機制或 retention 策略來控制。

概念位置

Mapping table 位在 backfill、data reconciliation 與 migration gate 之間。Backfill 依它轉換資料，validation query 依它判斷 mismatch，incident decision log 則依它追溯當時的判讀依據。

可觀察訊號

系統需要 mapping table 的訊號是：

• 舊欄位混合多種業務語意，需要拆到新欄位
• 多個舊狀態會對應到同一個新狀態
• 某些舊狀態需要人工確認或例外處理
• 事後要能解釋 mismatch 是資料錯誤還是轉換規則錯誤

接近真實網路服務的例子

訂單服務把 pending_payment、paid、payment_failed、refunded 對應到 payment_state 的 pending、captured、failed、refunded。這張 mapping table 同時支撐 backfill job、validation query 與 cutover gate。

設計責任

Mapping table 要保留來源欄位、新欄位、對應理由、例外狀態與 owner。高風險 mapping 要版本化，並進入 evidence package；否則資料漂移時，團隊很難判斷問題出在資料、程式還是規則本身。

概念位置

網站憑證生命週期位在 TLS / mTLS 與 secret management 的交界。它同時影響可用性、資安與操作成本，因為憑證過期、鏈錯誤或私鑰洩漏都會直接影響服務可用性。

可觀察訊號與例子

系統需要網站憑證生命週期設計的訊號是服務會公開提供 HTTPS。電商網站在促銷高峰若遇到憑證過期，使用者會直接遇到瀏覽器安全警示並中斷交易。

設計責任

設計要定義簽發方式、部署邊界、過期門檻 alert、續期演練、撤銷流程、權限分離與 runbook。高流量站點應把憑證健康納入 dashboard 與停機演練。

概念位置

Search index 是 read model 的一種實作。正式狀態仍由 source of truth 管理（relational DB、document DB），search index 透過 CDC、event subscription 或 ETL 同步更新。概念上跟 materialized view 類似 — 都是為特定查詢需求預先準備的資料形狀。

在觀測領域，log storage 的 search index（Elasticsearch / Loki 的 label index）承擔 log 查詢的效能。Index 的欄位選擇跟 cardinality 影響查詢延遲跟儲存成本，見 4.1 log schema。

使用情境

商品搜尋、文件站搜尋、客服多條件檢索、log 查詢通常都需要 search index 提供低延遲查詢體驗。Elasticsearch、Algolia、Meilisearch、Typesense 是常見實作。

設計責任

設計時要定義索引更新延遲（source 變更到 index 可查的時間）、重建流程（index 損壞或 schema 改版時的 full reindex）、查詢語意（全文 vs 結構化 filter）與權限過濾（search 結果是否要按使用者權限過濾）。Index 是 derived state — 修復方式是 rebuild 而非直接修改。

概念位置

ACME 自動化是 website certificate lifecycle 的簽發與續期機制。它通常和 ingress、CDN、load balancer 或 API Gateway 整合，確保多節點部署時維持一致憑證狀態。

可觀察訊號與例子

系統需要 ACME 自動化的訊號是站點數量增加、環境增加或憑證更新頻率提高。多網域 SaaS 服務若使用手動續期，憑證遺漏更新的風險會快速上升。

設計責任

設計要定義 challenge 類型、失敗重試、續期窗口、憑證分發、失敗 alert 與回復 runbook。網域與 DNS 權限要和 least privilege 對齊。

概念位置

憑證鏈與信任根是 TLS / mTLS 成功握手的基礎。鏈配置錯誤、根憑證不受信任或中繼遺失，都會造成 HTTPS 連線失敗。

可觀察訊號與例子

系統需要這個設計的訊號是不同平台連線結果不一致。網站在桌機正常但行動裝置失敗，常見原因是中繼憑證配置不完整或舊裝置信任根差異。

設計責任

設計要定義憑證鏈部署方式、兼容策略、檢測腳本與故障 runbook。運維流程要把憑證鏈檢查納入部署 gate 與例行健康檢查。

概念位置

常見做法是把檔案 metadata 放在資料庫，內容放在 object storage，並用 key 連結兩者。 可先對照 Observability Middleware。

可觀察訊號與例子

例如使用者上傳附件、報表匯出、備份封存，通常都會走 object storage 路徑。

設計責任

設計時要定義存取權限、下載時效、版本策略、保留期限與刪除流程，避免檔案生命週期失控。

概念位置

續期與輪替是 website certificate lifecycle 的穩定性核心，並與 downtime 風險直接相關。流程設計不完整時，憑證到期會直接造成服務中斷。

可觀察訊號與例子

系統需要續期與輪替設計的訊號是憑證有效期縮短或多環境併行部署。支付入口在到期日前未完成灰度更新，可能在流量尖峰觸發連線失敗。

設計責任

設計要定義到期門檻 alert、灰度部署、回滾條件、私鑰輪替、兼容測試與驗證清單。變更後應以 dashboard 追蹤握手錯誤率與憑證剩餘天數。

概念位置

Local worker 常搭配 in-process channel 與 worker pool；若需求轉向跨節點可靠處理，通常要改用 durable queue。

可觀察訊號與例子

例如非關鍵通知、短週期快取刷新、定時清理記憶體資料，可先由 local worker 承擔。

設計責任

設計時要定義停止行為、錯誤處理、隊列上限與 shutdown 合約，避免背景任務在重啟時遺失而不可見。

概念位置

憑證撤銷是 website certificate lifecycle 的事故處理能力，與 secret management 與 audit log 一起構成憑證風險控制邊界。

可觀察訊號與例子

系統需要撤銷流程的訊號是金鑰材料疑似外洩或錯誤部署到不該公開的環境。若缺少撤銷與替換流程，攻擊者可能持續利用舊憑證偽裝服務端點。

設計責任

設計要定義撤銷觸發條件、責任人、替換時序、客戶端影響評估、溝通流程與回復 runbook。事故後要以 post-incident 更新偵測與輪替策略。

概念位置

Delivery semantics 直接影響 retry policy、idempotency、dead-letter queue 與 replay runbook 設計。

可觀察訊號與例子

例如支付事件通常需要高可靠與去重；typing indicator 通常可接受遺失。兩者應使用不同的 delivery semantics。

設計責任

設計時要把語意寫入事件合約與操作流程，避免不同服務對同一事件有不同預設而造成隱性風險。

概念位置

Read model 是 CQRS 的讀取面產物。在 CQRS 架構中，write model 跟 read model 各自獨立，read model 透過同步機制（event handler、CDC、定期刷新）從 write model 更新。

Read model 的來源可以是 projection（從 event log 持續推算）、materialized view（從 SQL 查詢預計算）、CDC consumer（從 row change 同步到搜尋索引）或批次 ETL（定期從 OLTP 匯出到 analytics store）。不同的來源機制有不同的更新延遲跟維護成本。

在觀測領域，recording rule 跟 rollup 扮演類似 read model 的角色 — 從 raw time series 預計算聚合結果，讓 dashboard 讀取預聚合資料而非重算 raw data。

設計責任

設計 read model 時要定義同步延遲（read model 落後 write model 多久可以接受）、重建流程（read model 損壞或 schema 變更時如何從頭重建）、欄位語意（read model 的欄位定義跟 write model 可能不同）與查詢邊界（這個 read model 能回答什麼問題、不能回答什麼問題）。

Read model 是派生狀態，修復方式是「砍掉重建」而非直接修改。把 read model 當正式狀態修改會導致 write model 跟 read model 分岔、後續同步覆蓋修改。

概念位置

Incident severity 連接 alert、runbook 與 escalation policy。同一類技術錯誤在不同業務場景可能有不同等級，因此分級要以產品後果為主。

可觀察訊號與例子

系統需要分級模型的訊號是事件發生後團隊對嚴重度判斷不一致。付款成功率下降與單一內部報表延遲都可能由 timeout 引起，但前者需要立即啟動高優先級處置，後者通常走一般排程修復。

設計責任

分級要定義等級條件、升級門檻、負責角色、通訊頻率與回顧要求。等級規則應定期和事故紀錄對照，避免長期失真。

概念位置

指揮系統連接 incident severity、escalation policy 與 incident timeline。常見角色包括 incident commander、technical owner、communication owner 與 scribe。

可觀察訊號與例子

系統需要指揮系統的訊號是事故期間同時出現多個聊天室與多個口頭指令。若沒有單一指揮窗口，團隊容易同時做出互相衝突的切換與回滾。

設計責任

指揮系統要定義角色責任、決策權限、交接規則與值班補位流程。事故結束後應回看決策時間線，調整角色設計與授權邊界。

概念位置

常與 Service Registry、load balancer、健康檢查與部署平台整合，決定流量如何導向健康節點。

設計責任

設計時要定義查找條件、轉譯規則與回復條件，避免流量導向未準備好的實例。

概念位置

Config Rollout 位在 configuration source、deployment platform 與 running instances 之間。它通常與 service discovery、container runtime、feature flag、secret management 或配置中心一起出現。 可先對照 Connection Pool。

可觀察訊號

系統需要 config rollout 的訊號是：

• 同一版程式要搭配不同環境設定
• 設定變更可能影響流量、權限或依賴連線
• 希望設定可以分批驗證與回復

接近真實網路服務的例子

新增下游 endpoint、切換第三方金鑰、調整 feature flag、更新來源白名單或變更 retry policy，都屬於 config rollout 問題。

設計責任

設計時要定義設定來源、分發順序、驗證方式、回復方式與影響範圍。Config Rollout 應該讓設定變更可預測，而不是把風險藏在部署流程裡。

概念位置

Service Registry 位在 deployment platform、health check、service discovery 與 load balancing 之間。它負責維持「目前有哪些實例可用」這份資料。 可先對照 Session Invalidation。

可觀察訊號

系統需要 service registry 的訊號是：

• 服務實例會動態擴縮
• instance 需要在啟動後自動登錄
• instance 失效時要自動摘除
• 呼叫端需要依據 metadata 找到合適實例

接近真實網路服務的例子

Kubernetes 會把 pod、labels 與 endpoint 維持成可查找狀態；service mesh 會用 registry 資料決定流量要導向哪個 instance；服務縮容時若 registry 沒有及時摘除舊實例，呼叫端就可能打到已下線節點。

設計責任

Service Registry 要定義註冊來源、heartbeat 或 TTL、失效摘除條件、metadata 結構與回復方式。它的重點是讓查找方拿到可信且更新的實例資料。

概念位置

升級策略是 incident severity 的執行流程，並與 alert runbook 與 incident command system 一起運作。

可觀察訊號與例子

系統需要 escalation policy 的訊號是高嚴重度告警在深夜長時間無回應。付款 API 中斷若 10 分鐘內沒有確認接手，應自動升級到下一層 on-call 與 incident commander。

設計責任

升級策略要定義回應時限、升級路徑、通知通道、交接內容與最終責任人。策略要定期演練，確認通訊資訊與值班名單有效。

概念位置

Handover protocol 位在 on-call、incident command system 與 escalation policy 之間。它承接角色切換、班次結束與事故升級時的資訊交接。

可觀察訊號與例子

系統需要 handover protocol 的訊號是：事故已經持續一段時間、原本負責的人要下班、或指揮權需要轉給下一位。若沒有明確交接，常見問題是重複排查、遺漏已嘗試過的措施，或對下一步有不同理解。

設計責任

Handover protocol 要明確包含當前狀態、已知事實、已嘗試動作、阻塞點、下一個檢查時間、對外溝通狀態與接手確認。交接完成前，責任歸屬應保持單一，不要同時存在多個實際決策者。

概念位置

常搭配 readiness、graceful shutdown 與 service discovery。

設計責任

設計時要定義每批比例、健康檢查門檻、回滾條件與流量切換節奏。

概念位置

Timeline 連接 alert 觸發（事故何時被偵測到）、on-call 回應（何時開始處理）、操作紀錄（做了什麼）、影響變化（使用者影響何時改善 / 惡化）跟 post-incident review（復盤時重建因果鏈）。

Timeline 也是 incident decision log 的時間軸基礎 — decision log 記錄「在這個時間點、基於這個觀測、做了這個決策」，timeline 提供「這個時間點」的上下文。

使用情境

系統需要 incident timeline 的訊號是事故後大家對「先發生什麼」說法不同。若沒有一致時間軸，復盤時很難判斷哪個操作真正帶來改善、哪個決策在當時是合理的。

設計責任

Timeline 要包含時間戳（UTC、精確到分鐘）、訊號來源（哪個 dashboard / alert / 人為觀察）、操作內容（restart / rollback / scale）、決策理由與結果驗證。記錄方式應簡潔且可在高壓下維持更新 — 事故中寫 timeline 的成本太高會導致沒人寫。Slack channel pinned message 或事故管理工具的自動 timeline 是常見實作。

概念位置

Runtime Config 位在 environment variable、config file、secret injection、feature flag 與 application startup 之間。它決定服務如何取得執行所需的參數與開關。 可先對照 Sampling。

可觀察訊號

系統需要 runtime config 的訊號是：

• 不同環境要使用不同參數
• 某些值必須由部署平台或 secret management 注入
• 服務需要可預期的預設值與覆寫順序

接近真實網路服務的例子

資料庫連線字串、第三方 API base URL、限制值、路由開關與功能旗標，都屬於 runtime config 的一部分。

設計責任

設計時要定義設定來源優先序、缺值行為、型別驗證、啟動失敗條件與是否允許動態更新。Runtime Config 應該讓服務在不同環境中保持一致的配置語意。

概念位置

常使用 CPU、QPS、queue lag 或自訂業務指標作為擴縮容條件。 可先對照 Backfill。

設計責任

設計時要定義擴縮容門檻、冷啟動成本、最小/最大實例與保護策略，避免擴縮容震盪。

概念位置

Blast radius 與 degradation、failover 與 rollback-strategy 密切相關。影響面判斷會直接改變事故分級與處置策略。

可觀察訊號與例子

系統需要 blast radius 判斷的訊號是單點異常開始波及更多路徑。某個推薦服務超時最初只影響商品頁，若重試策略失控，可能進一步拖慢共用 database 與 checkout 路徑。

設計責任

影響面設計要標出依賴拓撲、共享資源與隔離手段。事故期間應持續更新影響面估算，並把結果同步到指揮與通訊流程。

概念位置

常出現在高風險功能、實驗功能與跨租戶差異化控制。 可先對照 Full-Text Search。

設計責任

設計時要定義旗標生命週期、預設值、回退策略與清理節點，避免旗標長期堆積。

概念位置

Incident communication channel 位在 incident command system、incident timeline 與對外通知流程之間。它讓指揮者、執行者、利害關係人與客服能在同一節奏上更新狀態。

可觀察訊號與例子

系統需要 incident communication channel 的訊號是事故時資訊散落在多個聊天群、會議室與郵件串，導致外部說法不一致。常見例子包括內部 war room、對外 status update、客服同步與管理層簡報。

設計責任

Incident communication channel 要定義主要通道、備援通道、更新頻率、對象分層與發言權限。對外公告不應和內部推進混在同一個通道，避免把未確認資訊直接擴散出去。

概念位置

回滾策略連接 incident severity、blast radius、cutover / switchover 與 fallback plan；是否放行變更則會受 Release Gate 影響，而實際可行性則應由 Rollback Rehearsal 驗證。

可觀察訊號與例子

系統需要 rollback strategy 的訊號是新版本上線後出現錯誤率上升。若回滾可在 5 分鐘內顯著降低使用者影響，通常優先回滾，再在低風險環境分析根因。

設計責任

回滾策略要定義觸發條件、資料相容性檢查、回滾步驟、停止條件與回滾後驗證。高風險變更應在發版前先演練回滾流程。

概念位置

Webhook 通常需要來源驗證、重放防護、重試處理與可追蹤事件 ID。 可先對照 Website Certificate Lifecycle。

設計責任

設計時要定義簽章驗證、時窗限制、冪等處理與錯誤回應策略，避免假請求或重放造成狀態錯誤。

概念位置

Rollback window 位在 cutover / switchover、fallback plan 與 incident decision log 之間。Rollback strategy 說明回退決策，rollback window 說明這個決策在目前階段是否仍可執行。

可觀察訊號

系統需要 rollback window 的訊號是：

• expand、backfill、cutover、contract 每一階段的回退方式不同
• 舊版本或舊資料語意只能支撐一段時間
• cutover 後仍可 fallback read，但 contract 後只能資料修復或 fail-forward
• release gate 要判斷是否還能安全暫停或回退

接近真實網路服務的例子

資料庫 migration 在 expand 階段通常能回到舊讀取；backfill 階段可以暫停與重跑；cutover 後可回到 fallback read；contract 移除舊欄位後，回退會轉成資料修補或 fail-forward。這些差異都屬於 rollback window。

設計責任

Rollback window 要寫清楚目前階段、可用回退方式、最後可回退時間、資料相容性限制與 owner。它要進入 release gate 與 incident decision log，避免事故期間把已經關閉的退路當成可用選項。

概念位置

Rollback Rehearsal 位在 release gate、rollback strategy、migration 與 disaster recovery 之間。它是把回滾步驟實際走過一次的演練，文件審查無法替代實機驗證。 可先對照 Rollback Strategy。

可觀察訊號

系統需要 rollback rehearsal 的訊號是：

• 變更失敗時回復速度會直接影響使用者影響
• 團隊不確定回滾步驟是否真的可執行
• 高風險 migration 或 release 會同時影響資料與流量
• 權限、腳本、順序或相容性可能成為回復瓶頸

接近真實網路服務的例子

資料表結構變更前先在接近正式環境演練 rollback，可以確認舊欄位是否還能恢復、資料補回是否可逆、以及切回舊版本後是否還能接流量。服務替換前做 rollback rehearsal，也能驗證 DNS、load balancer 與設定切換的回復時間。

設計責任

Rollback Rehearsal 要定義環境、資料範圍、演練步驟、驗證項目與紀錄方式。演練的重點是找出「看似可回滾、實際回不去」的缺口。

概念位置

常見於 Web 與 App 需求差異明顯時，BFF 會整合多個下游 API 並回傳前端所需形狀。 可先對照 Blast Radius。

設計責任

設計時要定義聚合邊界、快取策略、超時控制與降級策略，避免單一 BFF 成為新瓶頸。

概念位置

復盤連接 incident timeline、rca 與 runbook 更新。它也是可靠性改進與工程優先序調整的輸入來源。

可觀察訊號與例子

系統需要復盤流程的訊號是同類事故反覆發生。若每次都只做當下修補，沒有形成結構化改進，事故頻率通常不會下降。

設計責任

復盤要包含影響摘要、時間線、根因、有效措施、無效措施、行動項與驗證期限。行動項需要指定 owner 與完成標準，避免停在會議紀錄。

概念位置

Fail-forward 位在 rollback window、containment 與 post-incident review 之間。Rollback window 關閉後，團隊仍需要一條能限制影響、補資料、完成相容收斂的前進路線。

可觀察訊號

系統需要 fail-forward 的訊號是：

• 舊資料語意已被 contract 或不可逆寫入移除
• 回退會造成更大的資料不一致或客戶影響
• 新路徑有明確修補方案、停損條件與 owner
• 事故 decision log 需要記錄為何不回滾

接近真實網路服務的例子

資料庫 migration 已完成 contract 後，舊欄位被移除，回到舊版本會讓讀取路徑失效。此時比較可控的做法可能是暫停部分寫入、修補 mismatch、補 validation query，再讓新路徑收斂到可用狀態。

設計責任

Fail-forward 要定義 containment、修補步驟、預期效果、停止條件與回寫項目。它要搭配 evidence package 與 action item closure，避免「不能回滾」被誤用成沒有證據的硬推。

概念位置

常包含編譯、單元測試、靜態檢查、契約驗證與安全檢查。 可先對照 Circuit Breaker。

設計責任

設計時要定義必要 gate、失敗回饋與執行時間上限，避免流程形同形式或過慢。

概念位置

RCA 是 post-incident-review 的分析骨架，並和 incident timeline 與 runbook 改進連動。

可觀察訊號與例子

系統需要 RCA 的訊號是事故說明只停在「某人操作錯誤」。更完整的分析通常還包含告警門檻不足、權限設計過寬、回滾流程不清楚等系統層因素。

設計責任

RCA 要建立證據鏈、假設邊界與可驗證改進。分析結果應轉成具體行動項，並與後續演練或測試串接。

概念位置

Stop condition 位在 migration gate、cutover-window 與 steady state 之間。Gate 說明能否開始，stop condition 說明開始後看到哪些訊號必須停。

可觀察訊號

系統需要 stop condition 的訊號是：

• rollout、backfill、replay 或 experiment 會逐批擴大影響
• 指標短暫變壞時需要知道是觀察、暫停還是回退
• owner 需要在事故現場快速做一致決策
• post-incident review 要檢查當時是否該更早停下來

接近真實網路服務的例子

資料庫 migration 可以定義 mismatch_rate >= 0.1% for two consecutive batches 或 replication_lag >= 30s for 10 minutes 作為 stop condition。達到條件時，團隊先暫停下一批 backfill 或回到 fallback read，而不是等使用者回報。

設計責任

Stop condition 要包含訊號、門檻、觀察窗口、對應動作與 owner。它要進入 release gate 和 incident decision log，並且要能被 evidence package 支撐。

概念位置

常在活動前、重大發版前或架構調整後執行，並觀察延遲、錯誤率與資源使用。 可先對照 Local Worker。

設計責任

設計時要定義流量模型、成功標準與可回應行動，避免只跑壓測數字而沒有決策結論。

概念位置

RTO 連接 downtime、failover 與 rollback-strategy。更短 RTO 通常需要更高操作準備與基礎設施成本。

可觀察訊號與例子

系統需要 RTO 的訊號是停機時間會直接影響收入或合約責任。付款服務若目標 RTO 為 15 分鐘，值班流程與切換能力都要圍繞這個目標設計。

設計責任

RTO 要對應分級、責任角色、演練頻率與驗證方式。設定後需用演練與真實事故資料驗證是否達成。

概念位置

Gate decision 位在 confidence、rollback window 與 incident decision log 之間。Checks 描述檢查結果，gate decision 把結果轉成放行、暫停、回退、fail-forward 或補證據。

可觀察訊號

系統需要 gate decision 的訊號是：

• CI、SLO、validation query 都有結果，但沒人知道下一步
• evidence 足以支持部分放行，但不足以支持完整 cutover
• 變更需要逐批 rollout、backfill、warmup 或 replay
• gate 要保留 owner 與 rollback window

接近真實網路服務的例子

資料庫 migration 的 gate decision 可以寫成 allow next 10% backfill; block customer-visible read cutover。這句話比 migration pass 更可操作，因為它同時說明允許前進的範圍與被擋住的風險面。

設計責任

Gate decision 要包含決策內容、支撐 checks、stop condition、rollback window 與 owner。它要能被 incident decision log 承接，讓放行後出現異常時能回放當時依據。

概念位置

常在預備環境或受控生產範圍執行，模擬節點失效、網路延遲、依賴不可用等情境。 可先對照 Checkpoint。

設計責任

設計時要定義故障範圍、停止條件、觀測指標與回復流程，避免測試本身造成失控影響。

概念位置

RPO 與 database、備份策略、replication lag 與 data reconciliation 緊密相關。RPO 越嚴格，資料保護與同步成本通常越高。

可觀察訊號與例子

系統需要 RPO 的訊號是資料遺失會造成財務或合規風險。訂單與付款資料若目標 RPO 接近零，需要更嚴格的持久化與回復設計。

設計責任

RPO 要定義資料類型分級、保護機制、驗證流程與例外處理。設定後應透過備份回復演練檢查實際可達成範圍。

概念位置

Projection 在 event sourcing 架構中扮演「event → current state」的推算角色。Event log 是 append-only 的事件序列，直接對 event log 做查詢效率低；projection 持續消費事件、維護可查詢的 read model，讓讀取端不需要每次 replay 整條事件流。

Projection 不限於 event sourcing。CDC（Change Data Capture）把資料庫的 row 變更推送到下游、下游建立搜尋索引或統計摘要，這也是 projection — 來源是 row change event 而非 domain event。觀測領域的 recording rule 也是一種 projection — 從 raw time series 持續推算預聚合的 metrics。

設計責任

設計 projection 時要定義四個面向：

更新策略：同步（事件寫入時立即更新 read model）或非同步（事件寫入後由背景消費者更新）。同步更新延遲低但耦合寫入路徑的效能；非同步更新解耦但 read model 有 lag。

重建流程：當 projection 邏輯改變或 read model 損壞時，需要從 event log 重新 replay 建立 read model。重建流程要能離線執行、不影響線上讀取。大量事件的 replay 可能需要數小時，設計時要估算重建時間跟資源需求。

正確性驗證：projection 是持續運行的計算，任何 bug 都會讓 read model 靜默偏離真實狀態。需要定期的 reconciliation（拿 projection 結果跟 event log 全量 replay 比較）來偵測漂移。

schema evolution：當來源事件的 schema 改版，projection 邏輯要能同時處理新舊版本的事件。這跟 event sourcing 的 upcasting 問題直接相關。

使用情境

需要 projection 的訊號是：讀取需求跟寫入結構不同（列表頁需要反正規化 view、搜尋需要全文索引、報表需要聚合摘要），而且這些讀取視圖需要隨資料變更持續更新而非批次重建。

常見的 projection 實作包括：event handler 更新 read DB、CDC consumer 更新 Elasticsearch index、Kafka Streams 維護 KTable、觀測 collector 做 log-to-metric 轉換。

概念位置

Rollback condition 位在 gate decision、rollback window 與 time range 之間。Stop condition 常用於流程何時停，rollback condition 則跟某筆已做出的 decision 綁在一起。

可觀察訊號

系統需要 rollback condition 的訊號是：

• rollback、fallback、degradation 或 fail-forward 本身也可能造成風險
• IC handoff 後，新 IC 需要知道什麼條件下要改路線
• stakeholder update 需要說明目前決策如何被監控
• PIR 需要檢查當時是否有明確撤回條件

接近真實網路服務的例子

客服後台切回 legacy status fallback 後，rollback condition 可以寫成 mismatch remains above threshold after 15 minutes。這表示 fallback 沒有降低錯誤時，團隊要改成資料修補或暫停相關入口，而不是繼續等待。

設計責任

Rollback condition 要包含訊號、門檻、觀察窗口、對應動作與 owner。它要連到 query link 與 time range，讓決策撤回成為可回放的證據判讀，口頭判斷的準確度和可追溯性都不足。

概念位置

MTTR 連接 incident severity、alert、runbook 與 post-incident-review。不同等級事故應分開計算，避免指標失真。

可觀察訊號與例子

系統需要 MTTR 的訊號是團隊想驗證事故流程是否改進。若新增 runbook 與升級策略後 MTTR 持續下降，表示流程變更有實際效果。

設計責任

MTTR 指標要搭配樣本數、嚴重度分層與影響範圍一起解讀。它應導向流程改善與演練設計，而不是單純追求數字下降。

概念位置

On-call 是 alert、incident severity 與 escalation policy 的執行入口。值班工程師是 alert 的第一個接收者，負責判斷「這個 alert 需要什麼等級的回應」。

On-call 跟 runbook 搭配運作 — runbook 提供行動指南、on-call 工程師執行。制度需要跟 dashboard 跟演練一起維護，避免值班只剩 pager 通知而沒有可執行流程。

使用情境

系統需要 on-call 制度的訊號是事故常在非上班時間發生、或跨區團隊需要連續處理。付款 API 夜間故障時，若沒有清楚值班安排，回復時間通常被人員定位延遲拉長。

設計責任

On-call 設計要定義排班週期、回應時限（critical alert 需要 N 分鐘內 ack）、交接格式（交班時把當前狀態跟未關閉事項傳給下一位）、升級路徑（on-call 解不了時升級到 tech lead / manager）與支援角色（secondary on-call 或 subject matter expert）。Alert noise 治理跟 on-call 品質直接相關 — alert fatigue 會讓值班品質退化。

概念位置

通常由 search index 提供，適合文件、商品描述與知識庫查詢。

設計責任

設計時要定義語言分析規則、索引更新延遲與查詢範圍，避免搜尋結果與產品預期落差。

概念位置

常與 search index 與 full-text search 搭配，提升查詢互動性。

設計責任

設計時要定義分面欄位、聚合成本與更新策略，避免高成本聚合拖慢查詢。

概念位置

Playbook 位在 incident command system、rollback-strategy 與 post-incident-review 之間。復盤後的改進常會沉澱成新的 playbook。

可觀察訊號與例子

系統需要 playbook 的訊號是某類事故反覆出現且處置步驟可預期。consumer lag 持續擴大、憑證即將過期、單區域流量異常等場景都適合建立專用 playbook。

設計責任

Playbook 要定義觸發條件、必要查詢、操作步驟、停止條件與回復驗證。內容應保持短而可執行，並在每次演練或真實事故後更新。

概念位置

這張卡位在 Game Day 附近，可和它一起看。

設計責任

設計時要定義輸入範圍、崩潰判定與回歸樣本保留，確保問題可重現與可修復。

概念位置

Game day 是 on-call、incident timeline 與 post-incident-review 的訓練場景。它把文件假設轉成可觀察行為與量化結果。

可觀察訊號與例子

系統需要 game day 的訊號是流程文件完整但實戰仍常卡住。團隊可在預備環境模擬 broker 中斷、database 延遲或憑證失效，觀察 MTTR 與升級節奏是否符合預期。

設計責任

Game day 要定義演練範圍、安全邊界、成功標準、紀錄方式與復盤輸出。演練設計應避免只測單一團隊，並包含跨角色溝通與決策節點。

概念位置

Ownership 連接 alert（每個 alert rule 需要 owner）、dashboard（每個 dashboard 需要維護者）、runbook（runbook 的更新責任跟服務 owner 一致）、incident severity 跟 escalation policy。

在觀測系統中，沒有 owner 的 alert 跟 dashboard 會隨服務演進退化 — alert 變成 noise、dashboard 變成裝飾。4.8 訊號治理閉環 的定期審視需要每個訊號都有明確 owner。4.18 operating model 定義 ownership 矩陣。

使用情境

系統需要 ownership 的訊號是同一事件在不同角色之間反覆轉手、或 alert 觸發後沒人知道該誰處理。Owner 離職但 alert / dashboard / runbook 沒有交接是常見的退化模式。

設計責任

Ownership 需要定義主責角色、協作角色、升級路由與關閉責任。Owner 變動時（離職、轉組）需要交接流程 — orphan alert / dashboard 的定期掃描是治理的一部分。每次服務邊界調整（新服務上線、服務合併）都應同步檢查 ownership 是否仍對齊。

概念位置

Little’s Law 連接「業務需求」跟「系統參數」。給定預期 RPS（λ）跟 SLO latency 上限（W）、能算出系統最大同時並發數（L）；反過來、給定 connection pool size（L）跟 latency 目標、能算出可支撐的 RPS。可先對照 Saturation Point。

可觀察訊號與例子

需要用 Little’s Law 反推的訊號是「不知道該訂多少 connection pool、thread pool、async worker」。例如：付款 API 預期 1000 RPS、SLO 是 p99 < 200ms、那麼穩態並發 ≈ 1000 × 0.2 = 200、connection pool 至少 200 + headroom。

設計責任

Little’s Law 只在穩態（steady state）下成立、不適用 burst transient。應用前要確認系統已度過 warmup、流量穩定才有意義。所有 stage（網路、應用、DB）都可獨立套用、用於 latency budget 分解。

概念位置

USL 解釋「加機器為什麼會失效」。線性擴容是理想、但實際系統有兩個拖累：α 是必須序列化的部分（如 lock、coordinator）、β 是節點間互相通訊的成本（如 cache invalidation、consensus quorum）。β 通常比 α 更危險、會讓 throughput 在 N 大到某點後反而下降。可先對照 Little’s Law。

可觀察訊號與例子

需要思考 USL 的訊號是「擴容到 N 個 instance 後、QPS 不再線性成長」。常見原因：共用 cache 變熱點、distributed lock 競爭、跨 region replication 變慢。對照案例：Spanner 用 TrueTime 降低 β 達成線性擴展；Coinbase RAFT 因 consensus 限制了水平擴容。

設計責任

設計分散式系統時、要主動識別 α 跟 β 來源、想辦法降低。常見手段：partition 切分（降 β）、sharding（降 α 的範圍）、避免 distributed lock（降 β）、async vs sync（降 α 的關鍵路徑）。USL 是 選型決策 的工具、不是 production runtime 的訊號。

概念位置

Saturation 不是「系統掛掉」、是「進入 latency 不可預測區」。健康系統運轉在 knee point 以下 50-70%。M/M/c queueing theory 顯示：utilization 接近 80% 時、queue length 跟 latency 指數成長 — 這個 80% 就是常見的 knee。可先對照 Little’s Law。

可觀察訊號與例子

Saturation point 出現的訊號是「pressure 增加 10%、latency 增加 100%」。對應案例：Tixcraft DynamoDB IOPS 從 20 衝到 135K — partition 設計均勻時 saturation point 推到極遠；hot partition 場景下 saturation point 提前出現、即使整體 capacity 還有餘。

設計責任

容量規劃必須先量出 saturation point、再以 headroom 規劃實際 capacity。沒有量過 saturation point 的系統等於「不知道距離崩潰多遠」。每次重大改動後 re-test、確認 knee 沒往不好的方向移。

概念位置

USE 是 resource-oriented 的觀察法、跟 request-oriented 的 RED method 互補。USE 回答「哪個資源先頂不住」、RED 回答「哪個 endpoint 表現變差」。容量規劃通常先看 USE 找瓶頸、再看 RED 看影響面。可先對照 Saturation Point。

可觀察訊號與例子

USE 三維度的典型訊號：CPU utilization 100% 但 saturation queue 空 → 還能撐；CPU 80% 但 run queue 不斷增長 → 已 saturate。對應案例：Lemino connection limit — utilization 看似還行、但 connection saturation 已爆。

設計責任

USE method 的關鍵是「不要只看 utilization」。utilization 是「目前用了多少」、saturation 是「排隊有多少在等」 — 後者才是 capacity 真正的領先指標。每個資源都要量三個維度、不能用 average 代替 percentile。

概念位置

RED 是 request-oriented 觀察法、跟 resource-oriented 的 USE method 互補。USE 看「資源層」、RED 看「業務層」。Duration 變差通常先於 Errors 出現 — 是 capacity 接近 saturation 的早期警訊。可先對照 SLI / SLO。

可觀察訊號與例子

RED 三維度的典型訊號：Rate 上升、Errors 維持低、但 Duration p99 飆升 → 接近 saturation；Rate 維持、Errors 飆升 → downstream 出問題（不是容量議題）。對應案例：GR8 Tech 25ms p95 — 把 p95 變業務 KPI 而非技術指標。

設計責任

每個 service / endpoint 必須有獨立 RED dashboard、不能只看全站 average。Duration 必須記錄分布（histogram）而非單一 percentile、否則無法做 long-tail 分析。RED metrics 通常驅動 SLO；duration 跟 latency budget 對接。

概念位置

Workload model 至少包含五個維度：平均吞吐、peak/avg ratio、操作 mix（read / write）、cohort 分布（geographic / device / tier）、burst pattern（時間集中度）。模型可以從 production access log + APM trace 抽出來、要定期 review 因為業務變化會讓模型過時。可先對照 Peak Forecast。

可觀察訊號與例子

模型過時的訊號是「壓測通過但 production 還是出事」。可能是 cohort 變了（VIP 用戶比例上升）、操作 mix 變了（新功能改變 read/write 比）、burst pattern 變了（新行銷活動）。對應案例：ASOS Black Friday 24h 1.67 億 峰均比 1.81x、跟 Tixcraft 5 分鐘賣完 的極端形狀差很多。

設計責任

設計時要決定「synthetic load」vs「production traffic replay」vs「混合」。synthetic 好控制但容易脫離 reality；replay 最貼真實但消耗下游資源；混合是常見折衷。模型必須驗證：壓測 同時 對比 production metrics、看誤差有多大。

概念位置

Tail latency 通常由以下因素貢獻：GC pause、connection pool 競爭、cache miss、cross-zone network、retry storm。average / p50 平滑掉這些 outlier、看不到 capacity 警訊；p99 / p999 直接反映「最不順的 1% / 0.1% 用戶看到什麼」。可先對照 Saturation Point。

可觀察訊號與例子

tail latency 飆升的訊號是「average 還行、用戶卻在抱怨慢」。對應案例：Tubi p99 < 10ms — ML inference 在 p99 才能控制體驗、p50 控制無意義；Coinbase sub-ms — RAFT 系統 p999 通常比 p99 高一個量級。

設計責任

SLO 通常訂在 p99、internal 可訂 p99.9。metrics 必須記 histogram、不是單一 percentile gauge。Java GC pause、Go GC、Node event loop lag 都可能造成 p999 異常、要單獨監控。tail latency 改善通常靠：減少 cross-zone hop、connection pool 預熱、避免 stop-the-world。

概念位置

DynamoDB / Cosmos DB / Bigtable / Cassandra 都用 partition 拆分資料、容量上限 = 每 partition 上限 × partition 數。但若 partition key 集中在少數 key（例如 event_id 一個演唱會、user_id 一個爆紅 KOL）、實際容量遠低於名義。Aurora / 傳統 RDB 沒 partition 抽象、但 hot row（高頻寫的單列）會引發 lock contention、效果類似。可先對照 Saturation Point。

可觀察訊號與例子

hot partition 的訊號是「整體 utilization 低、但 throughput 上不去 + p99 latency 飆」。對應案例：Amazon Ads 9000 萬 RPS — partition key 設計均勻避免 hot；Tixcraft 售票 — 同一場演唱會（event_id）天然容易 hot、必須用 composite key 或 write sharding 分散。

設計責任

設計 partition key 時、要主動評估「在最壞場景下、單一 partition 會吃多少流量」。常見手段：composite key（event_id + user_id_hash）、write sharding（event_id + random_suffix）、time-bucket（event_id + minute）。發現 hot partition 後、resharding 通常是高成本工程、要在設計初期避免。

概念位置

Forecast 方法分三層：歷史線性外推（適合 sustained growth）、季節性分解（STL，適合電商 / 串流）、業務 ML 模型（結合 marketing pipeline、新用戶獲取、留存）。最常見錯誤是「拿去年同期 × (1 + 預期成長 %)」 — 忽略產品改動 + 行銷投入變化 + 外部事件。可先對照 Headroom Budget。

可觀察訊號與例子

需要重新 forecast 的訊號是「上次 forecast 跟實際差超過 20%」或「業務有重大改動」（新 feature、新市場、新合作）。對應案例：Disney+ 新片發布 內容型 forecast；Zoom 30x COVID 外部衝擊讓 forecast 完全失效、必須 reset baseline。

設計責任

Forecast 必須有 誤差範圍、不能單一數字。給上下界（最壞 / 預期 / 最好）、容量規劃才能用 worst-case 訂 baseline。事件型 forecast 要按 tier 分級（regular / major / critical）、不同 tier 對應不同準備強度。Forecast 跟 headroom budget 一起算才有意義。

概念位置

Headroom 不是 over-provisioning 浪費、是容量規劃的安全邊界。三個動機：forecast 誤差（預測本身有 ±X% 誤差）、burst pattern（瞬間 spike 超過 average peak）、AZ / region failover（一個 AZ 掛、剩下兩個要承擔全部）。Stateless service 通常 30%、DB 50%、broker 60%。可先對照 Peak Forecast。

可觀察訊號與例子

Headroom 不足的訊號是「peak 期間 utilization 接近 80%、autoscaler 還沒反應」或「single AZ 故障演練時、其他 AZ 撐不住」。對應案例：GR8 Tech AI 預測 — 預測準了可以降 headroom 比例、預測不準必須拉高 headroom。

設計責任

Headroom 不是越大越好、會推高成本。要算 under-provisioning 成本（下事故的機率 × 影響）vs over-provisioning 成本（每月多花的錢）、找平衡點。Cost-sensitive 服務可以降 headroom 但加 reactive autoscaling；critical 服務拉高 headroom + pre-provision。每季 review headroom 比例。

概念位置

Predictive scaling 用兩類預測：歷史模式（過去幾週同時段、同 day-of-week 的流量）跟 ML 模型（多 feature 模型、結合業務 schedule、新用戶獲取）。EC2 Auto Scaling、GCP Compute Engine Predictive Autoscaler、Azure VM Scale Sets 都支援。跟 scheduled scaling 互補 — scheduled 處理「已知時間點」、predictive 處理「常態 daily / weekly pattern」。可先對照 Scheduled Scaling。

可觀察訊號與例子

需要 predictive 的訊號是「reactive autoscaler 反應太慢、流量上升期 latency 飆」。對應案例：GR8 Tech AI 預測 — 賽事高潮預測模型、把擴容窗口縮到反應時間之內；Prime Day pre-scaling — 結合 predictive + scheduled 兩種。

設計責任

Predictive scaling 預測錯了會浪費錢（預測過高、提前擴沒用到）或失效（預測過低、流量還是衝高）。要 monitor 預測準確度、超過誤差門檻時 fallback 到 reactive。三層組合最穩：scheduled（已知大事件）+ predictive（daily pattern）+ reactive（unexpected burst）。

概念位置

Scheduled scaling 適合：年度 / 季度活動（Prime Day、Black Friday、雙 11）、賽事（NFL Super Bowl、IPL 決賽）、行銷活動（產品發布、限量優惠）、內容發布（新片首映、新章節上線）。EC2 Auto Scaling 的 scheduled action、HPA 的 cron-based scaling、DynamoDB 的 scheduled capacity 都是實作。可先對照 Predictive Scaling。

可觀察訊號與例子

需要 scheduled scaling 的訊號是「事件型流量上升速度比 autoscaler 反應快」。對應案例：Prime Day 年增率 30-77% 提前算進容量；Tixcraft 售票 開賣前 30-60 分鐘 pre-scale ELB / EC2。

設計責任

Scheduled scaling 必須 提前足夠時間 啟動、不是事件當下才擴。pre-warm window 通常 30 分鐘到 2 小時（取決於 instance boot time、cache warmup、connection pool 預熱）。事件結束後也要 scheduled scale down、避免長期 over-provision。跟 predictive scaling 跟 reactive scaling 三層組合最穩。

概念位置

• Linear growth：用戶月增 X%、B2B SaaS 常見、forecast 線性外推
• Step growth：每次行銷 / 活動跳一階、需要 event tier 規劃
• Exponential growth：早期初創、病毒擴散、forecast 容易低估
• S-curve growth：成熟產品、會 saturate、需要規劃 mature stage 容量
• Cyclical：電商季節性、Black Friday + Cyber Monday + Christmas

可先對照 Peak Forecast。

可觀察訊號與例子

判讀 growth curve 的訊號是「過去 12 個月 MAU 圖形」。對應案例：Zoom COVID step growth（1000 萬 → 3 億）；Pokemon GO 50x surge exponential 之後可能 S-curve；ASOS Black Friday cyclical。

設計責任

設計容量規劃節奏時、要先判讀 growth curve 形狀、再選 forecast 方法。Linear 適合每月 review；step 適合 事件前後 review；exponential 適合每週 review；cyclical 適合按 cycle 規劃；S-curve 要規劃 maturation 後容量保持但成長放緩。curve 形狀變了（exponential 變 linear）也是策略訊號。

概念位置

Shadow traffic 跟 shadow read 不同 — shadow read 是 DB 層 replica；shadow traffic 是 application 層 traffic mirror。實作方法：GoReplay、service mesh shadow（Istio mirror）、AWS VPC Traffic Mirroring、自管 reverse proxy with mirror config。可先對照 Dark Launch。

可觀察訊號與例子

需要 shadow traffic 的訊號是「想驗證新架構是否能撐 production load、但不能讓用戶受影響」。對應案例：Tixcraft 10K t2.micro 壓測 — pre-event 壓測但走 staging；real shadow 則是 production-traffic-driven。

設計責任

Shadow traffic 也消耗 production 下游資源（DB write、API call、external service）— 必須算進容量。如果新版本寫入會影響真實狀態（payment、order），必須設計成 dry-run 或寫入 isolated sandbox。Shadow 通常跑 1-7 天看 long-tail 訊號、不是 30 分鐘就下結論。

概念位置

Dark launch 用 feature flag 控制 UI 暴露、後端走 production traffic（從內部 API、cron job、employee-only access 等觸發）。目的是先驗證後端在 production 規模下穩定、再開放給用戶。跟 shadow traffic 的差別是「shadow 不寫入真實狀態、dark launch 寫入但用戶看不到」。可先對照 Canary Perf Check。

可觀察訊號與例子

需要 dark launch 的訊號是「新功能後端有風險、想先 production-validate 再 ui-launch」。對應案例：SeatGeek Virtual Waiting Room 從第三方換到自建、必然有 dark launch 階段驗證 token 配發機制。

設計責任

Dark launch 必須有清楚的 exit criteria：穩定多久、誤差多少、可以開放 UI。要 monitor 後端 metric、用戶 metric 還沒意義。Dark launch 期間如果後端有 side effect（DB write、external API call），要算進容量規劃。

概念位置

Canary 流量導 1% / 5% / 10% 到新版本、跟 control（舊版本）流量比較 p50 / p95 / p99 / p999 latency 分布、throughput rate、resource saturation。自動 rollback 條件：canary p99 比 control 退化 > X%。漸進放大：通過 1% → 5% → 25% → 50% → 100%。可先對照 Profile Diff。

可觀察訊號與例子

需要 canary perf check 的訊號是「release 後 latency 飆但 error 沒事、用戶體驗悄悄變差」。對應案例：Prime Day pre-event 驗證 / FanDuel canary across 20 州。

設計責任

Canary perf check 的關鍵是 跟 control 比、不是跟 baseline 比。同樣流量同樣時段、不同版本的差才有意義。abort condition 要事前訂、不要事中決定。Canary 流量比例要看 退化 blast radius — 1% 流量退化 30%、影響 0.3% 用戶；50% 流量退化 30%、影響 15% 用戶。

概念位置

Canary release 位在 rolling update 與 release gate 之間。Rolling update 是逐批替換實例的機制，canary 是在替換過程中加入「先驗證再擴批」的決策層。Release gate 是每批擴大前的放行條件。可先對照 Canary Perf Check。

可觀察訊號

系統需要 canary release 的訊號是「版本切換需要控制 blast radius」。判讀要維持 per-version 視角——只看整體平均值會掩蓋新版本的局部退化。常見 stop condition 包含 per-version error rate 偏離、p95/p99 latency 惡化、依賴 timeout 連續超門檻、draining 未完成。

設計責任

Canary release 要定義三件事：切換單位（比例 / 區域 / 租戶 / 路由規則）、每批觀察窗口與停損條件、回退路徑（舊版本是否仍能承接回退流量）。效能退化的檢查見 Canary Perf Check。Canary 決策的 evidence 格式見 Evidence Package。

概念位置

Profile diff 的常見實作：Brendan Gregg 的 differential flame graph、Pyroscope diff、Datadog Continuous Profiler diff、Parca compare。輸入是兩個 profile（同樣 sampling 條件下取得）、輸出是「新版本比舊版本多花了多少 CPU / memory / lock time」。可先對照 Continuous Profiling。

可觀察訊號與例子

需要 profile diff 的訊號是「release 後 latency 退化、不知道是哪段 code 拖累」。對應案例：Netflix Aurora 統一 — DB 層統一後 profile 變單純、profile diff 更容易識別 application 層的退化來源。

設計責任

Profile diff 必須在 相同負載 + 相同硬體 + 相同 sampling rate 下取得、否則結果無意義。看「相對變化幅度」而非絕對 CPU%。Diff 結果通常需要工程師判讀、不能純自動化判斷退化是否可接受 — 因為「多花 20% CPU 但 throughput 多 50%」可能是 好變化。

概念位置

Continuous profiling 是 metrics、log、trace 之外的第四角觀測訊號。Metrics 告訴你「CPU usage 上升了」，trace 告訴你「某條 request 變慢」，profile 告訴你「變慢的那段程式碼是哪幾個 function call」。Profile 是唯一能精確到 callstack level 的觀測訊號。

Always-on 的核心價值是 baseline — 事故時跟 baseline 做 diff（flame graph diff），看「哪些 function 的 CPU 消耗跟平時不同」。

使用情境

需要 continuous profiling 的訊號是「latency 退化常找不到原因、靠事後重現很慢」或「同一段 hot path 反覆出現在事故 RCA 中但缺 baseline 資料」。版本升級後 latency 退化時，profile diff 能直接定位是哪個 function 變慢。

設計責任

Overhead 控制是 continuous profiling 可行性的前提 — CPU overhead < 1%、memory overhead < 10MB。eBPF-based profiler（Parca、Pyroscope eBPF）在 kernel 層採集、overhead 最低；language runtime 內建（Go pprof、Java JFR）居中。Profile 資料要帶 service / version / region label，讓跨版本 diff 跟 canary 對照可行。完整設計見 4.9 continuous profiling。

概念位置

Cost per request 是 FinOps 的最小單位。可以對齊業務 metric：cost per active user、cost per transaction、cost per ML inference。不同 endpoint 成本差很大：登入請求可能 $0.0001、結帳請求可能 $0.001（10x 差距）。可先對照 Headroom Budget。

可觀察訊號與例子

需要算 cost per request 的訊號是「月帳單上升但不知道誰造成的」。對應案例：Zomato TiDB → DynamoDB 50% 成本降 — 算出每筆計費事件的成本後決定遷移；Netflix Aurora 28% 成本降 — DB 層 cost-per-request 量化才能評估 consolidation 價值。

設計責任

Cost per request 必須包含 所有 stage：app compute、DB read/write、cache、network egress、第三方 API。常見漏算：跨 region egress、CloudWatch / Stackdriver / Application Insights metric 成本、log ingest 成本。每月 review、每季 right-sizing。

概念位置

Performance budget 訂在 SLO baseline 之上、允許「p99 比 baseline 高 X ms 連續 Y 分鐘」這類退化額度。額度用完 → release freeze → 修完 perf 再放行。跟 error budget 互補：error budget 控制可靠性退化、performance budget 控制效能退化。可先對照 Latency Budget。

可觀察訊號與例子

需要 performance budget 的訊號是「容量規劃太死板、新功能 release 太慢」或反之「release 太快、累積 perf 退化沒人管」。對應案例：Coinbase sub-ms 延遲就是收入、無 performance budget 等於無 release control；FanDuel 多 SLO 直播 vs 投注不同 budget。

設計責任

Performance budget 不是越緊越好、會 starve 產品創新。建議從 baseline + 10% headroom 開始、看 burn rate 調整。budget 用 burn rate alert（類似 error budget）、不是用門檻 alert。跟 latency budget 不同層：latency budget 是「每個 stage 多少 latency 配額」、performance budget 是「整體允許退化多少」。

概念位置

Latency budget 是 Little’s Law 的應用 — 給定吞吐目標 + latency 目標、反推每個 stage 的可承受 latency。常見分解：DNS 5ms + TLS 50ms + CDN 20ms + app 100ms + DB 30ms + serialization 10ms = 215ms。任何 stage 超 budget → 該 stage 必須改善。可先對照 Performance Budget。

可觀察訊號與例子

需要 latency budget 的訊號是「p99 latency 飆但不知道誰拖累」。對應案例：Coinbase sub-ms — 從 sub-ms 反推、每個 stage 都被擠到極限（Cluster Placement Group、z1d 等）；Tubi ML p99 < 10ms — feature lookup 10ms 內、model inference 才有預算。

設計責任

Latency budget 必須 跟 SLO 對齊、不是工程師憑感覺訂。每個 stage 的 budget 必須有 current measurement — 不能訂了沒量。Cross-region call 自帶數十 ms 不可壓縮 latency、設計時要明確認知。任何新增 stage（middleware / sidecar / interceptor）都會吃 budget、必須評估。

概念位置

Global OLTP 是 transaction boundary 在多 region 場景的延伸。它通常需要 quorum、跨區時鐘或排序協議，並把跨區延遲納入設計前提。可先對照 latency budget 與可用性目標（availability target）。

可觀察訊號與例子

需要 global OLTP 的訊號是「跨區交易順序錯誤會直接造成業務損失或合規風險」。例如支付、票務庫存、核心帳務。若業務可接受短暫不一致，多數情境可改用 eventual/session consistency，降低延遲與成本。

設計責任

設計 global OLTP 時要先定義三件事：一致性目標、可接受延遲上限、區域故障下的服務策略。若無法同時滿足三者，就需要調整資料分區、交易範圍或一致性層級，而不是直接加硬體。

概念位置

SLO drift 來源：structural surge（COVID 類外部衝擊讓 baseline 永久上移）、product change（新 feature 改變用戶 journey）、architectural improvement（DB 換型、cache 加強、CDN 擴點）、user behavior（mobile share 上升、跨 region 比例變化）。drift 不是 anomaly、是 新常態。可先對照 SLI / SLO。

可觀察訊號與例子

需要重新校準 SLO 的訊號是「最近 N 個月 burn rate 持續低於 baseline」或「持續高於 baseline 但無 incident」。對應案例：Zoom 30x COVID surge — baseline 從 1000 萬 DAU 永久升到 3 億、SLO threshold 跟著重新校準。

設計責任

SLO 必須每季 review、不是「設定後就忘」。review 流程：拉過去 90 天 SLI 分布、看 percentile 分布是否跟 SLO 對應、看是否需要調整。drift 確認後要更新：alert threshold、autoscaler trigger、performance budget 額度、容量規劃 baseline。對應 error budget 跟 performance budget。

概念位置

Distributed SQL 介於單區域 relational database 與最終一致的 key-value 之間。它通常使用 consensus 協議、分區與複寫，來支撐 global-oltp 或高可用 OLTP。可對照 database 與 partition。

可觀察訊號與例子

需要 distributed SQL 的訊號是「單機或單主架構已成長瓶頸，且業務仍要求交易一致性」。常見例子是跨區帳務、全球訂單、強一致庫存。若業務主要追求吞吐且可接受不一致，NoSQL 或事件流設計通常更划算。

設計責任

選 distributed SQL 要明確評估三項代價：跨節點協調延遲、容量預留、運維複雜度。若只看峰值吞吐而忽略協調成本，會在故障與擴容時暴露結構性風險。

概念位置

Database sharding 位在單一 primary database 與 distributed SQL 之間。MySQL + Vitess、PostgreSQL + Citus、MongoDB sharded cluster 或 application-layer sharding 都會把 shard key 變成資料路由契約；Distributed SQL 則把更多 routing、一致性與 failover 責任放回 database layer。

可觀察訊號與例子

需要 database sharding 的訊號是單一 primary 的 write throughput、storage、maintenance window 或 tenant isolation 已成瓶頸，且 workload 可以用 tenant_id、user_id、region 或 business key 切成相對獨立的資料集合。MySQL 進入 Vitess / PlanetScale 討論時，核心問題通常是 shard key、VSchema、resharding workflow 與跨 shard transaction；PostgreSQL 進入 Citus 討論時，核心問題通常是 tenant co-location、distributed table 與 coordinator / worker topology。

Hot shard 的訊號是整體資源還有餘裕，但少數 shard 的 write、lock、CPU 或 storage 先到上限。這時要同時看 Hot Partition、Saturation Point 與 Replication Lag，避免只增加節點數卻沒有修正 key distribution。

設計責任

設計 database sharding 要先定義 shard key、routing owner、single-shard query 比例、cross-shard query policy、cross-shard transaction policy、resharding path、backup / restore unit 與 incident owner。shard key 是長期資料契約，改動時常牽涉 backfill、dual-write、shadow read、cutover window 與 data reconciliation；因此要接回 Online Migration、Cutover Window 與 Data Reconciliation。

概念位置

PACELC 可讀成：若發生 partition（P），系統在 failover（A）與 consistency（C）之間取捨；否則（E），在 latency（L）與 consistency（C）之間取捨。它補足 CAP 只描述分區情境的盲點。

可觀察訊號與例子

需要 PACELC 判讀的訊號是「系統平時沒有故障，但延遲或一致性目標仍互相衝突」。例如跨區強一致交易會提高延遲；低延遲讀取通常要接受 stale risk。這個框架常用於比較 distributed-sql 與 key-value 設計。

設計責任

使用 PACELC 時要把業務需求先量化：可接受的 stale window、p99 延遲上限、故障時可降級策略。沒有量化目標時，PACELC 會退化成抽象口號。

概念位置

External consistency 常見於全球交易資料庫，需配合可驗證時間來源或排序機制。它可視為 linearizability 在跨節點、跨區域交易中的具體工程目標。可對照 transaction 與 global-oltp。

可觀察訊號與例子

需要 external consistency 的訊號是「交易先後顛倒會造成帳務、合約或稽核錯誤」。例如同一帳戶的扣款與退款、同一資產的買賣成交。若業務可接受短暫重排，多數情境不必承擔此級別成本。

設計責任

採用 external consistency 要同時設計延遲預算與失效處置。跨區確認必然增加延遲，因此要先界定哪些交易必須此語意、哪些可降級為較弱一致性。

概念位置

TrueTime 常用於 global-oltp 與 external-consistency 的實作。它把時間誤差顯式化，讓提交順序與可見順序在工程上可檢查、可推導。

可觀察訊號與例子

需要 TrueTime 類機制的訊號是「交易先後順序錯誤會造成業務不可接受後果」，例如全球帳務、跨區支付對帳。若業務可接受短暫重排，通常不需要承擔此級別時鐘成本。

設計責任

使用 TrueTime 思路時，要同時管理時間不確定區間、提交延遲與跨區 quorum 代價。若只看一致性語意而忽略延遲成本，系統會在高峰流量下失去可用性彈性。

概念位置

Session consistency 常出現在多區域資料庫的可調一致性模型，介於 external-consistency 與 eventual consistency 之間。它常用於高互動產品路徑，降低讀者看到「我剛改完卻看不到」的落差。

可觀察訊號與例子

需要 session consistency 的訊號是「同一使用者回看自己操作結果時，短暫不一致會造成信任下降」，例如個人設定、遊戲狀態、用戶偏好。若是跨使用者共享狀態，仍要額外評估全域一致需求。

設計責任

採用 session consistency 時，要明確定義 session 邊界、token/連線續存策略與跨裝置行為。若 session 定義模糊，會讓一致性語意在不同入口不一致，反而增加除錯成本。

概念位置

Bounded staleness 是一致性與延遲取捨的中間層，可搭配 pacelc 做設計判讀。它常用在跨區查詢、報表與次要讀路徑，降低全域強一致的延遲成本。

可觀察訊號與例子

需要 bounded staleness 的訊號是「使用者可接受短暫延遲，但不能接受長時間舊資料」，例如庫存瀏覽、內容列表、營運看板。若 stale window 超標，通常會觸發告警或降級策略。

設計責任

採用 bounded staleness 時，必須定義上限值、量測方法與超標處置。沒有 tripwire 的 stale window 只是口頭承諾，無法支撐 release gate 或事故判讀。

概念位置

CAP 只討論 partition 發生時的取捨，不直接回答「平時要快還是要一致」。因此實作決策通常要和 eventual-consistency 或 external-consistency 一起看，才不會把框架誤用成口號。

可觀察訊號與例子

需要 CAP 判讀的訊號是「跨節點連線不穩時，團隊還在要求同時零錯誤與零拒絕」。例如跨區交易系統在區域斷鏈時，若仍要求所有讀寫立即一致又完全不中斷，最終會讓故障處置策略自相矛盾。

設計責任

使用 CAP 時要先定義 partition 下的降級策略：拒絕寫入、接受舊資料、或只保留局部能力。沒有預先定義，事件當下就會把架構問題轉成人工決策壓力。

概念位置

Linearizability 比 eventual 或 session consistency 更強，通常需要跨節點協調與 quorum。它常用於金融帳務、票務庫存與交易撮合這類不能接受順序錯亂的路徑。

可觀察訊號與例子

需要 linearizability 的訊號是「操作先後顛倒會造成不可逆後果」。例如扣款與退款順序錯亂，會讓對帳失敗或合約狀態錯誤。

設計責任

採用 linearizability 時要同步管理兩件事：跨區延遲成本與失效時的可用性策略。只保證語意、不設回退與降級，會在網路抖動時讓服務品質急劇下降。

概念位置

在多區域系統裡，quorum 直接決定兩個結果：提交延遲下限與故障時可用範圍。節點距離越遠、同意門檻越高，延遲通常越高；但容錯能力也會提升。這層取捨通常要和 latency-budget 一起評估。

可觀察訊號與例子

需要 quorum 判讀的訊號是「跨區資料正確性要求高，但延遲目標仍按單區設定」。例如要求全球強一致卻同時要求跨洲 p99 低於 50ms，通常與 quorum 物理成本衝突。

設計責任

設計 quorum 時要明確寫下節點分布、門檻策略與區域失效劇本。這些條件若只存在於腦中，事件期間很容易出現錯誤切換或過度擴散的回退操作。

概念位置

Eventual consistency 常見於多區域 NoSQL、快取同步與讀寫分離系統。它不是「資料可以一直錯」，而是要明確定義可接受的收斂窗口，並以 bounded-staleness 或告警閾值管理風險。

可觀察訊號與例子

適合 eventual consistency 的訊號是「短暫舊資料可接受，但系統需要高可用與跨區吞吐」。例如社群動態、商品評論、推薦內容。若是支付、庫存扣減這類路徑，通常需要更強語意。

設計責任

採用 eventual consistency 時，必須定義補償與對帳機制，讓「最終一致」可驗證。沒有驗證路徑時，最終一致會退化成無法證明的假設。

概念位置

Consistency level 通常出現在多區域資料庫、快取同步與讀寫分離架構。它會直接影響延遲、可用性與資料新鮮度，因此要和 latency-budget 一起設計。

可觀察訊號與例子

需要 consistency level 判讀的訊號是「同一條業務路徑同時要求低延遲與強一致，但沒有分層策略」。例如把結帳交易與商品瀏覽套同一一致性設定，常會讓其中一邊承受不必要成本。

設計責任

定義 consistency level 時要先按業務路徑分層：哪些操作必須強一致、哪些可容忍短暫舊資料、超標時怎麼降級。沒有分層會讓整體設定退化成最保守或最冒險的單一極端。

概念位置

Control plane 常見於 service mesh、load balancer、Kubernetes 與 API gateway。它影響 data path 的行為，因此任何變更都可能造成大範圍連動，要和 blast-radius 一起治理。

可觀察訊號與例子

需要 control plane 判讀的訊號是「小配置變更引發大面積錯誤」。例如路由規則更新後，多個服務同時 5xx，通常是控制層變更把錯誤快速擴散到資料路徑。

設計責任

控制層變更要有分批發布、回退窗口與生效可觀測性。沒有這三項，控制層會變成高權限單點風險，事件時難以定位責任邊界。

概念位置

Release Gate 位在 migration、schema change、deployment、error budget 與 incident policy 之間。它把驗證結果轉成可執行的放行決策，並常搭配 Rollback Rehearsal 確認放行前後都能回復。

可觀察訊號

系統需要 release gate 的訊號是：

• 變更會影響使用者可用性或資料正確性
• 新舊版本會並存一段時間
• 團隊需要在 release 前確認檢查項都過關
• 發版失敗時要有明確阻擋條件

接近真實網路服務的例子

Schema migration 要先確認相容性與 backfill 結果再放行；高風險設定變更要通過 security review 與 drift check；error budget 快耗盡時，團隊可以暫停高風險變更，直到風險恢復到可接受範圍。

設計責任

Release Gate 要定義檢查項、擁有者、通過條件、阻擋條件與例外流程。它是把風險控制流程標準化的機制，單純的批准按鈕無法達到同等效果。

概念位置

Federation 常出現在 SSO、跨雲工作負載授權與第三方服務整合。它把外部事件導入內部授權鏈，因此要和 token-revocation 與 audit-log 共同設計。

可觀察訊號與例子

需要 federation 判讀的訊號是「外部身份事件發生後，內部權限收斂速度慢且回查困難」。例如供應商事件後，聯邦 token 仍在非預期服務活躍。

設計責任

聯邦信任要有定期重評估、分域撤銷與最小授權範圍。若只建立信任不做持續治理，federation 會把整合便利轉成長期風險擴散通道。

概念位置

Tripwire 位在 Security Exception、Release Freeze 與 Escalation Policy 之間。它把監控與流程訊號轉成「何時重新決策」的共通語言。

可觀察訊號

系統需要 tripwire 的訊號是：

• 例外決策存在到期與重評估需求
• 風險條件會隨版本、漏洞、外部公告持續變化
• 團隊需要在訊號達門檻時自動升級處理
• 治理決策需要可追蹤的觸發紀錄

接近真實網路服務的例子

供應鏈治理中，artifact 驗證失敗率連續超過門檻，tripwire 會觸發 release freeze 重評估；身分治理中，特權操作異常增長，tripwire 會觸發 exception 審查與權限收斂。

設計責任

Tripwire 要定義 trigger signal、threshold、escalation owner、decision route 與關閉條件。設計重點是訊號可量測、門檻可稽核、觸發後流程可執行。

概念位置

In-flight 是跨語境訊號：HTTP request、queue message、batch task 都可以有 in-flight。它和 queue-depth 一起看時，能區分「排隊壓力」與「處理壓力」的來源。

可觀察訊號與例子

需要 in-flight 判讀的訊號是「延遲上升但不確定是入口太快還是處理太慢」。例如 queue depth 平穩，但 in-flight 長期偏高，通常代表 worker 端處理速度下滑或下游依賴變慢。

設計責任

In-flight 需要可觀測上限與降載策略。沒有上限時，系統容易在壓力期把暫存資源耗盡，最後演變成全域超時或雪崩式重試。

概念位置

Security exception 位在 Release Gate、Release Freeze 與 Tripwire 之間。它承接治理層決策，並把決策資訊交給部署與 incident workflow。

可觀察訊號

系統需要 security exception 的訊號是：

• 修補窗口與業務時程暫時不一致
• 高風險項目需要短期過渡方案
• 團隊需要紀錄接受範圍與期限
• 關閉條件需要跨角色共識與可驗證證據

接近真實網路服務的例子

新漏洞公告後，某服務在修補完成前以例外方式允許受控上線，同步啟用補償控制（流量限制、額外審計、強化告警），並設定到期日與重評估會議時間。

設計責任

Security exception 要定義 risk scope、expiry、compensating controls、owner、close criteria 與 write-back target。例外成立的同時，也要同步設計關閉節奏與回寫路徑。

概念位置

Stale read 常出現在 replication-lag 拉開的 read replica、跨區同步、cache-aside 與異步 projection。它需要先定義可接受窗口與超標處置、是否構成錯誤取決於業務容忍度；判讀粒度跟 consistency-level 跟 bounded-staleness 對齊。

可觀察訊號與例子

需要 stale read 判讀的訊號是「使用者剛完成操作，下一次查詢卻看不到結果」。例如付款成功後，訂單狀態頁仍顯示未付款，通常是讀路徑落後寫入收斂。

設計責任

處理 stale read 要同時提供技術與產品策略：技術上可用讀回主庫、版本比對或延遲容忍設計；產品上要明確呈現狀態轉換，避免把短暫收斂延遲誤解成資料錯誤。

概念位置

Release freeze 位在 Release Gate、Allowlist 與 Tripwire 之間。它決定哪些變更先暫停、哪些必要變更可受控放行。

可觀察訊號

系統需要 release freeze 的訊號是：

• 漏洞修補、供應鏈事件或事故復原正在進行
• 關鍵控制面驗證尚未達到放行標準
• 高風險變更可能擴大影響範圍
• 團隊需要在短時間內穩定風險面

接近真實網路服務的例子

供應鏈事件期間，團隊暫停所有非必要版本更新，只允許修補與回復相關變更進入正式環境；每次放行都通過額外驗證與雙人審核。

設計責任

Release freeze 要定義 freeze scope、allowlist policy、validation gate、unfreeze condition 與例外審查流程，並把解除條件連回治理決策會議。

概念位置

Workload identity 常見於 Kubernetes、跨雲服務整合與 CI/CD 自動化、跟 authentication 對人類身份的處理對稱。它通常搭配 token-revocation 的短時 token 與 least-privilege 的最小授權範圍、降低憑證被竊取後的利用窗口。

可觀察訊號與例子

需要 workload identity 判讀的訊號是「機器授權來源不清、scope 過寬、事件後難以分域回收」。例如供應商事件後，內部多個服務仍使用同一聯邦 token 存活。

設計責任

設計 workload identity 時要定義三件事：簽發責任主體、token 生命周期、事件後收斂流程。缺少任一項，都會把身份治理退化成不可驗證的長期信任假設。

概念位置

Allowlist 位在 Input Validation、Release Freeze 與 Authorization 之間。它可以同時用於請求治理、變更治理與資源治理。

可觀察訊號

系統需要 allowlist 的訊號是：

• 需要在凍結期間保留少量必要變更
• 高風險操作需要先符合條件才能執行
• 團隊需要限制可用來源、版本或操作集合
• 放行規則需要可追蹤與可回顧

接近真實網路服務的例子

release freeze 期間，只允許安全修補版本與回復工具變更進入正式環境；資料匯出流程只允許特定角色與核准任務編號觸發。

設計責任

Allowlist 要定義允許對象、限制條件、有效期限、審查者與撤銷機制。放行條件要能被系統驗證，而不是依賴人工記憶。

概念位置

Artifact provenance 位在 CI Pipeline、Credential 與 Release Gate 之間。它連接建置流程、簽章機制與正式放行決策。

可觀察訊號

系統需要 artifact provenance 的訊號是：

• 需要確認 artifact 來源是否來自受信建置流程
• 部署前需要驗證簽章、摘要與版本關聯
• 供應鏈事件後需要快速判讀受影響範圍
• 團隊需要可追溯證據支援稽核與復盤

接近真實網路服務的例子

團隊在發佈前驗證 artifact 簽章與 digest，並比對建置紀錄與 commit 來源；若 provenance 證據缺口出現，release gate 直接阻擋放行並觸發治理流程。

設計責任

Artifact provenance 要定義來源證據欄位、簽章驗證流程、失敗處理路徑與證據保留策略，並把驗證結果寫入 release governance 與 incident workflow。

概念位置

Management plane 位在 admin-endpoint、trust-boundary、runtime-config 與 audit-log 之間。它需要和業務流量平面維持清楚邊界。

可觀察訊號與例子

系統需要管理平面治理的訊號是管理入口可由一般流量路徑到達，或管理操作缺少獨立稽核。邊界設備、雲端控制台、平台管控 API 都屬於管理平面。

設計責任

管理平面要定義存取邊界、操作審核、變更時序與責任鏈。事件發生時要能快速鎖定高風險操作入口，避免控制能力被橫向擴散。

概念位置

Session invalidation 位在 authentication、credential、incident-timeline 與 runbook 之間。它承接身分事件後的收斂節奏。

可觀察訊號與例子

系統需要會話失效機制的訊號是修補完成後仍觀察到可疑會話、異常登入地理分布或持續重放行為。邊界設備事件與 SSO 事件常需要全域會話失效。

設計責任

會話失效要定義觸發條件、覆蓋範圍、失效時序與驗證方式。設計上需要兼顧安全收斂速度與業務可用性。

概念位置

Token revocation 位在 authorization、secret-management、incident-severity 與 runbook 之間。它常與 token 分域策略一起使用。

可觀察訊號與例子

系統需要 token 撤銷能力的訊號是供應商事件後 token 仍可存取敏感資產，或可疑 token 在事件後持續被使用。OAuth token、API token 與 service token 都屬於常見對象。

設計責任

token 撤銷要定義分域、優先級、批次策略與可回查紀錄。事件中要能先撤銷高風險 token，再依業務優先級逐步恢復必要授權。

概念位置

Containment 位在 incident-severity、degradation、failover 與 rollback-strategy 之間。它先回答保護邊界，再回答恢復順序。

可觀察訊號與例子

系統需要 containment 的訊號是影響面快速擴大、異常行為跨服務傳播、或回復決策尚未完成。常見動作包含入口隔離、權限收斂、會話失效與流量切換。

設計責任

containment 要定義觸發條件、執行順序、停止條件與驗證關閉標準。它應該讓團隊在壓力下快速做出一致決策。

概念位置

Impact scope 位在 blast-radius、incident-timeline、post-incident-review 與 mttr 之間。它把技術事件映射到業務影響。

可觀察訊號與例子

系統需要影響面盤點的訊號是技術異常已確認，但受影響名單與業務衝擊仍不清楚。資料外送事件、供應鏈事件與跨部門中斷都需要 impact scope。

設計責任

影響面盤點要定義盤點粒度、資料來源、更新節奏與責任角色。事件中應先完成最小可用清單，再持續擴充精度。

概念位置

Status page 位在 incident communication channel、stakeholder mapping 與 post-incident-review 之間。它把內部節奏轉成客戶可讀的更新，並把 ETA、影響範圍與下一次更新時間固定下來。

可觀察訊號與例子

系統需要 status page 的訊號是事故已經影響外部使用者，但內部的戰情室節奏還不能直接交給客戶。常見例子包括區域性 outage、身份平台失效、外部供應商中斷與多租戶服務退化。

設計責任

Status page 要定義更新頻率、發佈責任、嚴重度標示、影響範圍與下一次更新承諾。它是外部信任的最小承諾面，用公關模板的心態維護會失去可信度。

概念位置

Stakeholder mapping 位在 incident communication channel、escalation policy 與 post-incident-review 之間。它把內部、客戶、管理層、法務與監管需求拆開，避免事故中漏通知或重複通知。

可觀察訊號與例子

系統需要 stakeholder mapping 的訊號是事故時通知對象不固定、每次都靠記憶補。常見例子包括：客戶已受影響但 account team 沒收到、法務通報窗口被錯過、或補償政策需要臨時討論。

設計責任

Stakeholder mapping 要定義角色群組、owner、通知頻率、升級條件與例外處理。它的目標是把責任鏈固定下來，名單長度本身沒有意義。

概念位置

Toil 位在 alert-fatigue、runbook 與 post-incident-review 之間。它把反覆出現的手動修復工作，轉成能被自動化或系統性消除的治理對象。

可觀察訊號與例子

系統需要 toil 治理的訊號是值班時間被重複修復工作吃掉，且每次事故後都只是多一個手動步驟。常見例子包括固定重啟、手動 replay、人工清 queue、或每週都要補同一份報表。

設計責任

Toil 治理要定義可自動化優先序、移除條件、owner 與替代路徑。它的目標是把沒有長期價值的重複成本逐步壓下來，消滅所有手工流程既不必要也不現實。

概念位置

Action item closure 連接 post-incident review（產出行動項）、runbook（行動項可能是更新 runbook）、4.8 訊號治理閉環（行動項可能是新增 alert / metric / dashboard）。

Detection gap 類的行動項（「事故中缺少某個 alert / metric」）應指派給觀測系統的 owner，帶明確的變更規格（新增哪個 metric、alert 閾值多少、連到哪個 runbook）。

使用情境

系統需要 action item closure 流程的訊號是事故復盤後大量 open items 超過 90 天仍未關閉，或同類事故重複發生但上次復盤的改善項還沒完成。

設計責任

每個 action item 定義：owner（誰負責完成）、完成標準（什麼狀態算 done — 不是「已開始」而是「已部署、已驗證」）、驗證方式（怎麼確認完成 — 跑一次演練、查 dashboard 確認 metric 存在）、截止時間（兩週內 close）。逾期的 action item 自動升級到管理層 — 這個升級機制是 closure 流程的背壓。

概念位置

Evidence package 位在 dashboard、SLI / SLO 與 post-incident review 之間。Dashboard 提供操作視角，SLO 提供判讀門檻，evidence package 保存支撐判斷的來源、時間窗、查詢入口與限制。

可觀察訊號與例子

系統需要 evidence package 的訊號是同一段事故證據在交班、release gate 或復盤時反覆被重新查證。常見例子是只保存截圖，下一班 on-call 看得到圖表形狀，卻缺少 query、time range、sampling ratio、ingest delay 與 owner，導致決策背景需要重新建立。

設計責任

Evidence package 要包含 source、time range、query link、owner、data quality、confidence、known gap 與 retention。它的責任是讓證據可查、可解釋、可重跑，並能交給 incident decision log、steady state 或 action item closure 使用。

概念位置

Time range 位在 dashboard、query link 與 incident decision log 之間。Dashboard 顯示狀態，query link 保留查詢入口，time range 則定義這次判讀看的時間範圍。

可觀察訊號

系統需要 time range 的訊號是：

• 同一張圖在不同時間重跑會得到不同結果
• release gate 要判斷某批 rollout 是否已穩定
• 事故交班需要知道某個 evidence 觀察的是哪段時間
• 復盤要對齊 deploy、alert、customer report 與 rollback 的先後

接近真實網路服務的例子

資料庫 migration 的 validation query 若標示 2026-05-11T02:10:00Z/2026-05-11T02:20:00Z，下一班 on-call 就能把 mismatch、replication lag 與 slow query 放回同一個 backfill batch 判讀。

設計責任

Time range 要定義開始時間、結束時間、時區、資料延遲限制與關聯事件。它應進入 evidence package 與 rollback condition，避免團隊用不同時間窗比較同一個決策。

概念位置

Incident decision log 位在 on-call、incident communication channel 與 post-incident review 之間。它保存的是決策內容、時間、證據、owner、預期效果與回退條件，timeline 則保存事故事件順序。

可觀察訊號與例子

系統需要 incident decision log 的訊號是事故結束後很難說清楚某次 rollback、degradation 或 vendor escalation 的決策依據。常見例子是聊天頻道有大量討論，但缺少明確的「何時決定、基於哪些 evidence、誰執行、什麼條件下改路線」。

設計責任

Incident decision log 要支援 handoff、multi-incident coordination、stakeholder update 與 post-incident review。它的欄位應足夠輕量，讓事故現場能持續更新，同時足夠完整，能把缺口回寫到 runbook、steady state 與 action item closure。

概念位置

Query link 位在 dashboard、validation query 與 incident decision log 之間。截圖適合溝通當下狀態，query link 則保留可回放、可調整、可驗證的入口。

可觀察訊號

系統需要 query link 的訊號是：

• 事故交班時下一班需要重跑同一個判讀
• release gate 要引用具體查詢結果，而不是貼圖表摘要
• PIR reviewer 需要查證當時資料限制
• dashboard panel 版本變動可能改變圖表語意

接近真實網路服務的例子

Checkout API evidence package 可以保存錯誤率 query、p95 latency query 與 provider timeout query 的連結。資料庫 migration evidence package 則可以保存 row count、mismatch sample 與 replication lag query link。

設計責任

Query link 要保留查詢版本、參數、time range、資料來源與 owner。它要搭配 known gap 記錄查詢未覆蓋的資料範圍，避免截圖或 dashboard 名稱被誤當成完整證據。

概念位置

Steady state 位在 error budget、blast radius 與 RTO / RPO 之間。它把可靠性承諾轉成可量測訊號，並說明故障期間哪些能力要維持、哪些能力可以受控退化。

可觀察訊號與例子

系統需要 steady state 的訊號是 chaos、failover 或 DR drill 只描述故障動作，缺少成功判準。常見例子是節點被關閉後 health check 仍為綠燈，但 checkout success、queue lag 或 client-side error rate 已經偏離使用者可接受範圍。

設計責任

Steady state 要包含 success rate、latency、queue lag、data correctness、customer impact 與 recovery complete 門檻。它的責任是支援 evidence package、incident decision log 與 game day 判斷實驗是否通過、事故是否恢復。

概念位置

Static stability 位在 control plane 與 blast radius 之間。它把控制面失效的影響限制在「新配置無法推送」，而非「現有服務中斷」。跟 steady state 的關係是：static stability 定義了控制面失效期間的 degraded steady state — 服務能力受限但仍在可接受範圍。

核心機制

Static stability 依賴三個機制：快取最後已知好配置（控制面失效時不嘗試重新取得）、預計算 fallback 路徑（控制面在線時就 build 好備用配置）、constant work pattern（失敗模式下的工作量跟正常時相同，避免 retry storm 放大負載）。

可觀察訊號與例子

需要 static stability 設計的訊號是控制面重啟或網路隔離時，資料面同時不可用。典型例子是 service mesh 的 control plane 掛掉後 sidecar 無法取得路由表、導致所有服務間通訊中斷；static stability 設計讓 sidecar 用快取的路由表繼續服務。

設計責任

Static stability 的責任是讓 DR 設計不依賴已故障的控制面。它跟 readiness 的關係是：static stability 是 readiness review 的前置項 — 若資料面沒有控制面失效時的自主能力，readiness 就有結構性缺口。

概念位置

Data quality 位在 metrics、trace 與 incident decision log 之間。Metric、log、trace、audit log 都可能有延遲、抽樣、drop、masking 或 schema drift，這些限制要跟證據一起交接。

可觀察訊號

系統需要 data quality 的訊號是：

• trace sampling 讓某些 request path 無法完整重建
• log pipeline 有 ingest delay 或 drop
• query 只跑 primary、replica 或部分 tenant
• dashboard 結論需要標示 freshness 或 completeness 限制

接近真實網路服務的例子

資料庫 migration 的 evidence package 可以標示 primary only; replica lag still recovering，表示 validation query 可信，但 replica 讀取路徑還不能用同一份 evidence 直接放行。

設計責任

Data quality 要標示 completeness、freshness、sampling、masking、retention 與 owner。它要支援 confidence 判讀，避免 release gate 或 incident decision log 把有限資料誤當成完整事實。

概念位置

Resiliency matrix 位在 blast radius 與 readiness 之間。它把失敗模式盤點（FMEA / pre-mortem）的產出結構化成可追蹤矩陣，並驅動 game day 演練題目的選擇 — gap 欄直接成為演練的優先目標。

可觀察訊號與例子

需要 resiliency matrix 的訊號是團隊知道有風險但不確定哪些已有防護。典型例子是高峰活動前的準備流程：把所有關鍵服務列成行、所有失敗模式（依賴斷線 / 容量超限 / 資料污染 / 配置漂移）列成列，逐格檢查防護狀態。Shopify 在 BFCM 準備中使用這個工具把年度驗證進度視覺化。

設計責任

Resiliency matrix 的責任是把 reliability debt 從模糊的「我們知道有缺口」變成可排序、可追蹤的清單。它的維護節奏跟 6.21 reliability debt backlog 對齊 — 每次演練後更新 matrix 的 gap/covered 狀態，每季 review matrix 的完整性。matrix 變成文件而不是工具（超過 6 個月未更新、gap 無 owner）是治理失敗的訊號。

概念位置

Confidence 位在 query link、known gap 與 incident decision log 之間。它不是情緒性的「我覺得」，而是基於證據完整度、資料限制與反向驗證狀態的判讀欄位。

可觀察訊號

系統需要 confidence 的訊號是：

• evidence 足以支持繼續 backfill，但不足以支持使用者可見 cutover
• 事故中某個根因還在 suspected 狀態
• release gate 需要分辨可以放行、暫停或補證據
• stakeholder update 需要避免把未確認資訊說成事實

接近真實網路服務的例子

資料庫 migration 的 evidence package 可以把 confidence 標成 suspected：validation query 顯示 mismatch 低於門檻，但 manual refund repair path 尚未被抽樣，因此只放行下一批 backfill，不放行使用者可見讀取 cutover。

設計責任

Confidence 要定義等級、證據依據、限制與下一步。它要與 known gap 和 rollback condition 一起保存，避免團隊把暫時結論當成穩定事實。

概念位置

Known gap 位在 confidence、query link 與 post-incident review 之間。Data quality 說明資料限制，known gap 則列出目前尚未被證據覆蓋的具體範圍。

可觀察訊號

系統需要 known gap 的訊號是：

• 某些 tenant、region、callback path 或 manual repair path 未被抽樣
• trace 或 log 缺少關鍵 span / field
• release gate 放行時仍有需要 follow-up 的證據缺口
• PIR 需要把缺口回寫成 readiness 或 observability 改善項

接近真實網路服務的例子

資料庫 migration evidence package 可以記錄 manual refund repair path not yet sampled。這個 known gap 會限制 cutover decision，並回寫成後續 validation query 或 audit log coverage 的改善項。

設計責任

Known gap 要描述缺口內容、影響範圍、目前風險、owner 與 follow-up。它要支援 confidence 分級，避免 evidence package 看起來完整，但實際漏掉高風險路徑。

概念位置

WAL 位在資料庫的 durability 與 recovery 機制核心。SQLite 的 WAL mode、PostgreSQL 的 WAL、MySQL InnoDB 的 redo log 都是同一個 write-ahead 原則的實作。它和記錄業務歷史的 Event Log 是不同層：WAL 是引擎內部的 recovery 結構，Event Log 是應用層可重播的事件流。

可觀察訊號與例子

需要理解 WAL 的訊號是寫入延遲、磁碟用量或 crash recovery 時間出現異常。WAL 檔持續長大通常代表 checkpoint 落後，或有長交易、inactive replication slot 卡住 log 回收；crash 後啟動變慢通常代表要重放的 WAL 區段過大。電商在尖峰寫入時若 WAL 成長速度超過 checkpoint，磁碟會先到上限。

設計責任

設計上要決定 WAL 的 checkpoint 頻率、保留長度、磁碟容量餘裕與監控指標。WAL 同時被 crash recovery、replication 與 CDC 三條路徑依賴，保留策略要同時滿足三者：保留太短會讓 replica 或 Replication Slot 追不上，保留太長會占用磁碟。observability 要看 WAL 生成速率、checkpoint lag 與最舊仍被保留的 log 位置。

概念位置

Recording rule 是 metrics 讀取路徑的效能工具。它在 TSDB 層（如 Prometheus、Thanos、Mimir）定期執行 query expression，把結果作為新 series 寫入儲存。概念上類似 OLAP 的 materialized view，但作用在時間序列而非關聯式資料。

設計責任

設計 recording rule 時要定義計算表達式、執行間隔、命名慣例與維護責任。命名慣例通常遵循 level:metric:operations 格式（如 job:http_requests_total:rate5m），讓讀者從名稱判斷來源、粒度與計算方式。

Recording rule 產生的 series 本身也佔儲存空間與 cardinality。規則數量增長時，要監控 rule evaluation duration 跟 rule group lag，避免 rule 跑不完的情況讓 dashboard 看到過期資料。

使用情境

需要 recording rule 的訊號是 dashboard panel 載入時間持續退化、或 alert rule 因為 query timeout 而漏發。把 SLO burn rate 計算、高流量 endpoint 的 rate 與 error ratio 預先聚合成 recording rule，是最常見的起點。

Recording rule 與 raw query 的分工：高頻讀取（dashboard 自動刷新、alert 每分鐘 evaluate）適合 recording rule；低頻即席查詢（事故時的 ad-hoc 切片）直接查 raw series，保留完整維度。

在觀測領域的應用見 4.2 metrics 聚合查詢 跟 4.23 觀測查詢設計。

概念位置

Metadata Lock 位在 DDL workflow 與 DML transaction 的交界。MySQL 的 metadata lock、PostgreSQL 的 ACCESS EXCLUSIVE lock 都是同一類機制 — 它讓一個看似輕量的 ALTER 在有長交易時放大成全表查詢停滯。它和 Transaction Boundary 直接相關：交易開得越久，越容易成為 DDL 的阻塞源。

可觀察訊號與例子

需要注意 metadata lock 的訊號是執行一個 ALTER 後，原本正常的查詢突然大量逾時或排隊。觀察 metadata lock 類系統表會看到 DDL 在等某個長交易、後面跟著一串 waiting 查詢。常見場景是部署期間跑 migration，剛好有一個忘了 commit 的交易或一個慢報表查詢，DDL 卡住、服務讀寫一起雪崩。

設計責任

設計 schema 變更要先定義 DDL window、lock wait timeout 與長交易的處理策略。安全做法是在低流量窗口執行、設定 DDL 逾時讓它快速失敗而非無限等待、並先找出與終止 blocker 交易。大表結構變更應改用 Online Migration 工具，把一次性鎖換成可控的漸進搬移。runbook 要能快速定位「DDL 在等誰」與「誰被 DDL 擋住」。

概念位置

Rollup 是 storage tiering 在時間維度的具體實作。它跟 recording rule 的差別在於：recording rule 是降維度（把多個 label 聚合成一條 series），rollup 是降時間精度（把 15 秒的點變成 5 分鐘的點）。兩者經常搭配使用。

設計責任

設計 rollup 時要定義每一層的精度、保留期、聚合函數與查詢路由規則。聚合函數的選擇影響查詢語意：對 counter 做 sum 跟對 gauge 做 average 是合理的；但對 histogram 做 average 會失去分布資訊。

查詢路由是 rollup 設計的關鍵配套。使用者查詢 7 天範圍時系統自動路由到 5 分鐘粒度、查詢 90 天範圍時路由到 1 小時粒度。若路由不透明，使用者會對精度差異產生困惑。

使用情境

需要 rollup 的訊號是 TSDB 儲存成本持續成長、長時間範圍的 dashboard panel 查詢逾時、或保留政策因為儲存限制被迫縮短。Thanos compactor、Cortex/Mimir compactor、VictoriaMetrics downsampling 都是常見實作。

在觀測領域的查詢設計見 4.2 metrics 聚合查詢 跟 4.23 觀測查詢設計。

概念位置

Read-Write Split 位在 application 與資料庫拓撲之間的路由層。它可以由 proxy、driver 或 application 自己實作；路由規則要分辨 write、一般 read、交易內讀取與需要強一致的讀取（例如 SELECT … FOR UPDATE）。它和 Replication Lag 直接耦合 — lag 越大，分流到 replica 的讀取看到舊資料的窗口越長。

可觀察訊號與例子

適合 read-write split 的訊號是 primary 的讀取壓力遠大於寫入、且多數讀取可以接受秒級延遲的資料。要特別處理的是「寫入後立刻讀」的流程：使用者送出訂單後馬上看訂單列表、後台改完權限馬上驗證，這些 read-after-write 路徑分到 replica 會讀到舊狀態。常見做法是讓這類路徑強制走 primary，或加一層 lag guard。

設計責任

設計時要定義路由規則、哪些讀取必須走 primary、交易內讀取如何 pin 在同一連線、以及 replica lag 超標時的降級策略。session 一致性要寫清楚：同一使用者的 read-after-write 是否保證。observability 要看 primary 與 replica 的讀寫分佈、replica lag，以及被 lag guard 擋回 primary 的比例。

概念位置

Storage tiering 是觀測資料管理的基礎設施層決策，影響查詢能力、成本結構與保留政策。它跟 rollup 的分工是：tiering 決定資料放在哪種儲存、rollup 決定資料以什麼精度存放。兩者共同構成觀測資料的生命週期管理。

設計責任

設計 tiering 時要定義每一層的查詢 SLA、儲存成本、資料轉移觸發條件與跨層查詢行為。

跨層查詢是 tiering 設計的關鍵問題。當查詢範圍橫跨 hot 跟 warm 兩層時，回應時間由最慢的那層決定。使用者在 dashboard 把時間範圍從「最近 1 小時」拉到「最近 7 天」時，查詢延遲可能從毫秒跳到秒級，體驗落差需要在 UI 或文件中說明。

使用情境

需要 tiering 的訊號是觀測儲存成本持續成長但大部分查詢只命中最近的資料、或保留期因為成本壓力被迫縮短導致鑑識與稽核需求無法滿足。Elasticsearch ILM、Loki 的 chunk storage 分層、Thanos / Cortex 的 object storage backend 都是常見實作。

Tiering 對查詢能力的影響見 4.7 cardinality 治理 跟 4.23 觀測查詢設計。

概念位置

Replication Slot 位在來源資料庫與下游 consumer 之間，是一個有狀態的 production resource。它和 Offset 都是消費進度，差別在反壓方向：offset 落後不會壓垮 producer，slot 落後會讓來源端為了保留 WAL 而吃光磁碟。PostgreSQL 的 replication slot 是典型例子，Consumer Lag 是它對應的健康指標。

可觀察訊號與例子

需要監控 slot 的訊號是來源資料庫磁碟用量上升、但寫入量沒有等比增加。常見原因是 Debezium connector 或 replica 離線，slot 仍在保留 WAL。一個 inactive slot 在高寫入服務上可以在數小時內撐爆 primary 磁碟，屬於高優先事故訊號。

設計責任

每個 slot 要有明確 owner、健康 SLO 與 drop condition。設計上要監控每個 slot 的 retained WAL 大小與 confirmed 位置，對 inactive slot 設告警，並定義「consumer 永久退場時誰負責 drop slot」。slot 數量與保留策略要納入來源端的容量規劃，讓複製能力不會反過來成為來源資料庫的可用性風險。

概念位置

Materialized view 是 read model 的一種實作方式。在關聯式資料庫中它是 SQL-level 的物化查詢；在觀測領域，recording rule 扮演類似角色 — 把聚合計算的結果寫成新的 time series。兩者的共同設計問題是更新頻率、一致性延遲與維護成本。

設計責任

設計 materialized view 時要定義刷新策略（定時 / 觸發 / 手動）、資料新鮮度容忍上限、儲存成本與失效重建流程。刷新頻率決定讀取的 freshness — 每分鐘刷新的 materialized view 最多落後一分鐘，對 dashboard 場景通常足夠，對即席事故診斷可能不夠。

使用情境

需要 materialized view 的訊號是同一個複雜查詢被多個消費者反覆執行（dashboard panel、定期報表、alert rule），而且每次查詢的計算成本高到影響原始資料源的效能。在觀測場景中，SLO burn rate、跨服務 error ratio、多維度 latency percentile 是常見的 materialization 候選。

在資料庫的應用見 1.8 State Ownership。在觀測領域的應用見 4.23 觀測查詢設計。

概念位置

Transaction Pooling 位在 application 與資料庫之間的 Connection Pool 內。相對於 session pooling（連線綁定整個 client session）與 statement pooling（綁定單一語句），transaction pooling 在壓縮率與相容性之間取中間值。選它就要把 search_path、prepared statement、暫存表、advisory lock、SET 等 session 層設定全部改成 transaction-scoped。

可觀察訊號與例子

適合 transaction pooling 的訊號是大量短連線、client 連線數遠超過資料庫能承受的後端連線上限。要特別注意依賴 session 狀態的功能：用 SET 設定的 Row-Level Security session 變數若不是 transaction-scoped，會漂到下一個 client 的 transaction，造成跨租戶資料外洩。

設計責任

設計時要先盤點 application 用到哪些 session 層機制，再決定 pooling 模式。選 transaction pooling 時要把租戶識別、權限變數、時區等設定改用 SET LOCAL 綁在 transaction 內。observability 要看後端連線使用率、client 等待時間，以及和 pooling 模式相關的錯誤。

概念位置

CQRS 是一種架構分離策略，位於資料存取模式的設計層。它跟 read model 的關係是：CQRS 是分離的決策框架，read model 是分離之後「讀取面」的具體產物。

CQRS 經常跟 event sourcing 一起出現，但兩者是獨立概念。CQRS 只要求讀寫模型分離；event sourcing 是把寫入模型改成 append-only 的事件流。可以有 CQRS 但沒有 event sourcing（寫入仍用傳統 CRUD，讀取用獨立的 read model），也可以有 event sourcing 但沒有 CQRS（讀寫都直接操作 event store）。

讀寫不對稱的三個維度

分離的動機來自三種不對稱，當任一種超過單一模型能承受的範圍時，CQRS 開始有設計價值。

形狀不對稱：寫入時資料以正規化、事務安全的結構進入系統；讀取時不同消費者需要不同的反正規化形狀。一個訂單寫入時是 order + line items + payment 三張表的事務；列表頁需要扁平的 order summary，報表需要跨訂單的聚合，搜尋需要全文索引。強迫同一個模型同時服務這些形狀，會讓寫入模型變得過度複雜或讀取效能退化。

頻率不對稱：讀取頻率遠高於寫入頻率是常見的服務模型（商品頁的瀏覽量遠大於商品更新頻率）。讀寫共用模型時，高頻讀取的效能需求會推動寫入模型往讀取最佳化靠攏，犧牲寫入的簡潔性跟一致性保證。

SLA 不對稱：不同讀取消費者的延遲容忍跟一致性需求不同。即時顯示需要毫秒級回應但容忍短暫不一致；報表需要完整一致但容忍分鐘級延遲；稽核需要長期可查但容忍更高延遲。單一模型難以同時滿足多種 SLA。

分離的設計判準

讀寫不對稱存在不代表一定需要 CQRS。分離的判準是不對稱的程度是否已經超過「在同一個模型上做最佳化」能解決的範圍。

可以不分離的情境：讀寫形狀接近（CRUD 應用、管理後台）、讀取消費者單一（只有一種 UI）、流量規模讓讀寫共用模型的效能足夠、團隊規模小到維護兩套模型的成本大於效能收益。

需要考慮分離的訊號：讀取效能持續退化但寫入側無法再為讀取最佳化（加 index 已到極限、反正規化導致寫入複雜度上升）；多種讀取消費者對同一份資料有互斥的形狀需求；讀寫的擴展需求方向不同（讀取要水平擴展、寫入要強一致性）。

分離的代價

CQRS 的代價集中在同步、一致性與維護三個面向。

最終一致性：read model 透過事件或同步機制從 write model 更新，中間有延遲。使用者寫入後立即讀取可能看不到自己的變更。這個延遲窗口需要被明確設計（多長、可接受嗎、UI 怎麼處理）而非假裝不存在。

同步機制的可靠性：write model 到 read model 的同步本身是一個需要監控跟治理的資料路徑。同步失敗、同步延遲、同步漂移都需要被偵測跟處理。

多模型維護：schema 變更需要同時更新 write model 跟所有 read model。read model 的數量增長後，每次 schema migration 的變更面會擴大。

跨領域的應用

讀寫分離的設計張力不限於 application data。觀測資料的讀取路徑設計（4.23 觀測查詢設計）面臨同樣的不對稱：寫入是高吞吐的 append-only，讀取被至少三種不同 SLA 的消費者（即席診斷、聚合趨勢、鑑識回溯）拉扯。觀測領域用 recording rule、rollup、storage tiering 來實作讀寫分離，概念上對應 CQRS 的 read model，但術語跟實作層級不同。

Message queue 的消費端也有類似結構：同一份事件被多個 consumer 以不同速度、不同形狀讀取，fan-out 跟 consumer group 是另一種讀寫分離的實作。

概念位置

Single Writer Model 位在並發模型的一端 — 寫入併發度上限為一。它和「多 reader 並行」可以共存：SQLite WAL mode 允許多個 reader 與一個 writer 同時運作。要擴展寫入時，靠的是改變架構（例如分區、分庫或換成 Distributed SQL），增加 writer 在此模型下行不通。

可觀察訊號與例子

single writer 仍夠用的訊號是寫入可以用一個 writer 排隊完成、busy 或 lock timeout 偶發且短。需要重新設計的訊號是寫入長期排隊、busy timeout 從偶發變成常態。常見誤判是把 busy timeout 調大當成擴容 — 那只是讓請求等更久；也常見多個 instance 同時寫同一個檔案，破壞 single writer 假設。

設計責任

設計時要明確指認「誰是 writer」並確保系統真的只有一個。LiteFS 類方案用 primary lease 把 writer 角色集中；應用層要把寫入路徑收斂到單一節點或單一序列化點。容量規劃要把單 writer 吞吐當作硬上限，超過時改走分區或 Distributed SQL，而不是疊加 writer。

概念位置

Event sourcing 是一種資料持久化策略，改變的是「狀態怎麼被記錄」而非「狀態怎麼被讀取」。它跟 CQRS 經常搭配但概念獨立 — event sourcing 處理寫入模型（append-only event log 取代 mutable row），CQRS 處理讀寫分離。可以有 event sourcing 但沒有 CQRS（讀寫都直接操作 event store），也可以有 CQRS 但沒有 event sourcing（寫入仍用 CRUD）。

Event sourcing 的儲存層是 event log。讀取面透過 projection 把事件流轉換成查詢用的 read model。

設計判準

Event sourcing 的設計價值來自「需要完整變更歷史」的業務需求。判準是：業務是否需要回答「某個時間點的狀態是什麼」或「狀態怎麼從 A 變成 B」。

適合的場景：

• 金融帳務 — 餘額的每一筆增減都是 audit 事件，法規要求能追溯任意時點的 balance
• 訂單流程 — 每個狀態轉換（建立→付款→出貨→完成）是 business event，需要重建任意階段
• 法規合規 — 完整變更歷史是合規證據，刪除或覆寫正式紀錄違反要求
• 需要 replay 能力 — downstream consumer 落後或資料損壞時，能從 event log 重建

不適合的場景：

• 簡單 CRUD — 狀態覆寫即可、不需要歷史、event sourcing 的 overhead 遠大於收益
• 需要直接查 current state 的高頻場景 — 每次讀取都 replay 整條事件流延遲太高，必須搭配 projection 維護 snapshot，增加系統複雜度
• 事件 schema 變更頻繁 — 舊事件需要被新版 schema 正確 replay，schema evolution 成本高

代價

讀取複雜度：current state 不再是一筆 row，而是需要 replay 或 projection 推算。讀取路徑的設計從「查一筆 record」變成「維護多個 read model + 保證 projection 正確性 + 處理 projection lag」。

事件 schema evolution：事件一旦寫入就不可變，但業務需求會改變事件結構。版本化 event schema（upcasting）是長期維護的核心挑戰 — 新版 projection 要能正確消費舊版事件。

儲存成長：事件永不刪除（或只做 retention），儲存量隨時間持續成長。高頻寫入的系統可能需要 snapshot 機制（定期存一份 current state 快照，replay 從 snapshot 開始而非從頭）來控制 replay 時間。

除錯難度：bug 可能是某個 event handler 在 replay 時產生錯誤結果。除錯需要重現特定事件序列的 replay，比查一筆 mutable record 的 diff 更複雜。

跟其他概念的關係

• Event log — event sourcing 的儲存層，append-only 的事件序列
• Projection — 把 event log 轉換成可查詢的 read model 的機制
• Read model — projection 的輸出，為特定查詢需求最佳化的資料形狀
• CQRS — 讀寫分離的設計框架，event sourcing 是其中一種 write model 實作
• Saga — 跨服務的分散事務，event sourcing 提供每個 step 的事件紀錄

概念位置

Embedded Database 位在 Database 這個傘狀概念下、與 server-side database 相對的一端。server-side database 有獨立 process、連線協定與營運團隊；embedded database 的 production boundary 在裝置與檔案生命週期 — 資料庫的可用性等同那個檔案與那個 Single Writer Model process 的可用性。

可觀察訊號與例子

適合 embedded database 的訊號是單一 process 內的本地狀態、測試 fixture、桌面或行動 app 的本地儲存，或邊緣節點上讀多寫少的資料。需要重新評估的訊號是多個 process 或多台機器要同時寫同一份資料 — 那已超出 embedded database 加 single writer 的設計範圍。

設計責任

設計時要明確指認檔案的 owner、backup 方式、崩潰後的復原流程與並發寫入的邊界。backup 要在一致的時點取，避免複製到寫入中途的檔案；corruption 要先保全原檔再修復。要跨裝置或跨節點共享資料時，要把同步當成獨立問題，接回 Local-First 與 Conflict Resolution。

概念位置

Conflict Resolution 位在多寫入來源收斂成一致狀態的關鍵環節。常見策略有 last-write-wins、欄位層合併、CRDT，以及交給人工或伺服器裁決；每種策略對「哪一筆寫入會被保留」給出不同答案。它和 Eventual Consistency 相鄰：最終一致描述系統會收斂，conflict resolution 描述它收斂到什麼結果。

可觀察訊號與例子

需要明確 conflict resolution 的訊號是同一份資料會被多個裝置或多個區域並發修改。last-write-wins 實作簡單，但會在兩個使用者同時編輯時靜默覆蓋其中一份 — 對筆記、購物車、協作文件這類場景等於資料遺失。欄位層合併能保留兩邊改的不同欄位，CRDT 能讓特定資料型別自動收斂。

設計責任

設計時要先依資料型別與業務後果選策略，再決定衝突要不要讓使用者看見。刪除要當成可傳播的事件處理（tombstone），讓離線裝置上的刪除能正確同步出去。observability 要能看到衝突發生率與被覆蓋的寫入量，讓 last-write-wins 的代價是可量測的，而不是隱形的。

概念位置

Row-Level Security 位在 application 授權的下游。application 層的 Authorization 決定「誰能呼叫這個功能」，RLS 決定「即使查詢送到資料庫，引擎也只回傳這個角色該看到的 row」。它和 Tenant Boundary 的差別在執行者：tenant boundary 是跨層的隔離概念，RLS 指明由資料庫引擎在 query 執行時強制過濾。

可觀察訊號與例子

適合 RLS 的訊號是多租戶 SaaS、需要資料庫層兜底防止跨租戶外洩，或合規要求資料存取有獨立 enforcement。RLS 通常依賴 application 在交易內設一個 session 變數（例如 tenant_id）來判斷；這個變數的生命週期要和 Transaction Pooling 的綁定模式對齊，否則會漂到別的請求。table owner 與 superuser 預設會繞過 RLS，這點要納入設計。

設計責任

設計時要讓 policy 覆蓋 SELECT、INSERT、UPDATE、DELETE 四種操作，並為緊急例外存取留 Audit Log。RLS 要有獨立測試，證明跨租戶查詢確實被擋下。它是兜底防線，application 層授權仍要做 — 兩道防線各自承擔不同的失敗模式。

概念位置

At-Rest Encryption 位在儲存層，與傳輸層的 TLS / mTLS 形成對稱的一組保護。in-transit 加密保護資料在網路上移動的階段，at-rest 加密保護資料靜止在儲存媒介的階段；一條完整的保護鏈兩者都要有。它和 Data Classification 連動 — 資料分級決定哪些資料必須做 at-rest 加密。

可觀察訊號與例子

需要 at-rest encryption 的訊號是儲存 PII、金流或受監管資料，或合規要求磁碟與 backup 加密。常見的保護鏈破洞是主資料庫加了密，但 backup 以明文落到 object storage — 攻擊者取得 backup 就繞過了所有加密。設計時要把 backup、replica 與暫存檔都納入加密範圍。

設計責任

設計時要決定加密範圍、金鑰管理方式與金鑰輪替策略。加密後資料能否還原取決於金鑰是否健在，因此 restore 演練要連金鑰一起測。金鑰要有 owner 與輪替排程，並和存取用的 credential 分開管理 — 兩者失敗代價不同：金鑰遺失等於資料無法還原，credential 外洩等於存取邊界失效。observability 要能確認加密設定狀態與金鑰可用性。

概念位置

Table Partitioning 位在單機資料庫的表結構層。它和 messaging 的 Partition 名稱相近但語意不同：Partition 切的是事件流、處理並行與順序；table partitioning 切的是一張資料庫表、處理查詢範圍與資料生命週期。要跨節點水平擴展時，才接到 Database Sharding。

可觀察訊號與例子

適合 table partitioning 的訊號是一張表很大、但查詢通常只碰最近一段時間或某個範圍，例如時序事件表、訂單表。time-based 分區讓「清掉 90 天前資料」變成卸載一個分區，而不是大範圍 DELETE。要特別注意的訊號是查詢沒帶分區鍵 — 規劃器無法做 partition pruning，查詢會退化成掃描全部分區。

設計責任

設計時要讓分區鍵和最常見的查詢條件對齊，並規劃分區的建立與卸載流程。time-based 分區要有自動建立未來分區、自動卸載過期分區的機制，並接回 Retention。observability 要看查詢是否命中 pruning，以及 default 分區是否意外累積資料。

概念位置

Local-First 位在資料架構的一端，與「伺服器是唯一真相、客戶端只是視圖」相對。它把問題拆成兩層：本機的讀寫與持久性是一層，多端的收斂是另一層。本機層用 Embedded Database 解決；收斂層要面對順序、權威來源與 Conflict Resolution，並和 Eventual Consistency 相鄰。

可觀察訊號與例子

適合 local-first 的訊號是行動或桌面 app 需要離線可用，或互動要求即時回饋，例如筆記、待辦、現場作業 app。需要謹慎的訊號是強一致需求：付款餘額、庫存、權限這類資料若每次都要看到最新的全域狀態，要先設計 read-after-write 路徑，而不是套用純 local-first。

設計責任

設計時要先界定哪些資料是 local-first、哪些必須即時和伺服器一致。同步層要決定權威來源、衝突策略，以及刪除如何傳播。observability 要能看到每個裝置的同步落後程度與待同步的本機變更量，讓「離線多久」是可量測的。

概念位置

Document Store 位在資料模型光譜上、和嚴格關聯式 schema 相對的一端。它可以是獨立的 document database，也可以是關聯式引擎內的 JSON 欄位或 document API。它適合放整份一起讀取的聚合資料；當資料間關係變多、需要 join 與跨文件一致性時，要回到關聯式建模或拆出 Read Model。

可觀察訊號與例子

適合 document store 的訊號是資料以「一份完整文件」被讀寫、形狀因來源而異，例如使用者 profile、第三方整合 payload、feature flag 設定。需要重新評估的訊號是巢狀文件變成主要關聯模型，或 JSON 路徑變成核心查詢條件 — 這時要把熱欄位抽出來建 index，或把這部分 relationalize。

設計責任

設計時要決定哪些資料適合文件、單份文件多大、哪些 JSON 路徑需要 index，以及 schema 演進怎麼做。文件型資料仍需要 Schema Migration 的紀律 — 欄位語意改變時要有版本與相容策略。observability 要看文件大小分佈，以及熱查詢路徑是否有 index 支撐。

概念位置

OLAP Offload 位在 OLTP 與分析系統之間的決策點。OLTP workload 是大量短交易，OLAP workload 是少量長查詢、掃大量資料；兩者放同一個資料庫會互相競爭 buffer、CPU 與 IO。卸載的路徑有 read replica、引擎內建的分析加速器，或用 Change Data Capture 同步到資料倉儲。

可觀察訊號與例子

需要 OLAP offload 的訊號是報表或分析查詢一跑，線上交易的延遲就升高。輕量做法是把分析查詢導到 read replica；查詢更重、要跨多來源或讀長期歷史資料時，要把資料同步到專門的分析系統。需要評估的取捨是資料新鮮度 — replica 與倉儲都有同步延遲，分析結果不是即時的。

設計責任

設計時要先量化分析 workload 的形狀（頻率、掃描量、並發），再選卸載路徑。要明確分析側可接受的資料延遲，並讓它成為 SLO 的一部分。observability 要能分開看 OLTP 與 OLAP 的資源用量，確認卸載後主庫的交易效能真的被保護。

概念位置

Key Management 位在加密機制的底層。At-Rest Encryption 與 TLS / mTLS 都假設金鑰存在且可用；金鑰一旦遺失，加密資料就無法還原。它和 Secret Management 相鄰但責任不同：access secret（password、API key）外洩造成存取邊界失效，data-encryption key 遺失造成資料永久無法讀取。

可觀察訊號與例子

需要正視 key management 的訊號是系統用了 at-rest 加密、TLS 或 application-level 加密，卻沒有明確的金鑰 owner 與輪替排程。常見失敗是 restore 演練時才發現備份的 keyring 沒有一起保存，加密的 backup 變成無法還原的資料。雲端的 envelope encryption 與 customer-managed key 把金鑰階層攤開，讓輪替與撤銷可以分層進行。

設計責任

設計時要定義金鑰階層、每把金鑰的 owner、輪替週期與撤銷流程，並把金鑰納入 restore 演練。data-encryption key 要和 access secret 分開保存與分開稽核。observability 要能確認金鑰可用性、最近輪替時間與即將到期的金鑰。

概念位置

Replica Identity 位在變更事件的 schema 契約層。Change Data Capture 與 Logical Replication 負責把變更傳出去，replica identity 決定那些事件本身帶不帶得出「改了哪一列」。多數情況 primary key 就是 replica identity；沒有 primary key 的表（某些 audit table、join table）要明確補一個唯一 key 或設定 full row image。

可觀察訊號與例子

需要檢查 replica identity 的訊號是下游套用 update / delete 時出現資料漂移或事件被丟棄。常見場景是一張沒有 primary key 的表進入 CDC pipeline，insert 事件正常、update / delete 事件卻無法對應目標列。這類問題通常是靜默的 — 資料慢慢不一致，而不是立刻報錯。

設計責任

設計 CDC 或邏輯複製前，要先盤點每張要輸出變更的表是否有穩定 key。沒有 primary key 的表要補唯一鍵，或接受 full row image 的成本。observability 要能偵測下游套用失敗或被略過的 update / delete 事件。

概念位置

Logical Replication 位在複製粒度光譜的一端。實體複製複製的是 storage 的 byte / page，整個 cluster 一起、版本綁定，適合 HA 與整體還原；logical replication 解碼成 row 事件、可選表、可跨版本，適合 CDC、跨系統同步與漸進遷移。它依賴 Write-Ahead Log 作為變更來源，用 Replication Slot 追蹤進度。

可觀察訊號與例子

適合 logical replication 的訊號是只需要部分表、要跨大版本升級、或要把資料送到非同種系統。需要注意的訊號是 schema 變更：發佈端改 schema 時，訂閱端與下游 consumer 要協調，否則事件欄位對不上。它和實體複製是互補關係 — 許多系統同時用實體複製做 HA、用 logical replication 做資料整合。

設計責任

設計時要決定哪些表進入 logical replication、schema 變更如何在發佈端與訂閱端協調，以及 slot lag 的監控與告警。要明確它和實體複製各自承擔 HA 與資料整合的哪一塊。observability 要看 replication lag、slot 保留量與套用錯誤。

概念位置

Break-Glass Access 位在日常權限與緊急需求之間。Least Privilege 讓角色平時只拿必要權限；事故有時需要超出平時的存取，break-glass 讓這個提權是有流程、有時限、可回收的。它和 Security Exception 的差別在形態：security exception 是對已知風險的書面豁免決策，break-glass 是執行中的緊急存取流程。

可觀察訊號與例子

需要 break-glass 機制的訊號是事故處理偶爾需要 production 高權限，但平時不該有人持有。沒有 break-glass 流程時，團隊常落入兩種有問題的做法：長期保留 admin 後門，或事故當下臨時亂開權限而沒有紀錄。健康的 break-glass 會在每次啟用時留下工單、申請人、時間窗與事後審查結果。

設計責任

設計時要定義誰能啟用、啟用要綁哪種工單、權限的自動回收時限，以及事後審查由誰做。每次 break-glass 啟用都要進 Audit Log。break-glass 流程本身要定期演練，確認事故當下真的拿得到、事後真的收得回。

概念位置

Read-After-Write 位在一致性保證光譜上、比 eventual consistency 強的一端。它通常是 session 範圍的保證：同一使用者的寫入，自己後續讀得到。在用 Read-Write Split 的架構下它要特別設計，因為讀取分流到有 Replication Lag 的 replica 時，剛寫入的資料可能還沒同步。

可觀察訊號與例子

需要 read-after-write 的訊號是使用者送出資料後會立刻看結果：下單後看訂單、發文後看貼文、改設定後回設定頁。這些路徑讀到舊狀態會被當成「資料遺失」的 bug。提供保證的常見做法是讓這類讀取走 primary、加 lag guard、或在 session 內 pin 到能看到自己寫入的來源。

設計責任

設計時要列出哪些讀取路徑需要 read-after-write 保證，並為它們選實作方式。要明確保證的範圍：是同一 session、跨 session、還是全域。observability 要能量到分流到 replica 的讀取中，有多少落在 lag 窗口內而可能讀到舊資料。

概念位置

Tombstone 位在「刪除如何被當成事件」的環節。在單一資料庫內，刪除就是移除一列；但在有副本、有離線裝置或有 CDC 下游的系統裡，直接移除會讓其他端不知道「這筆被刪了」。tombstone 把刪除變成一筆可傳播的標記，和 Eventual Consistency 一起讓刪除能收斂。它的保留期限要接回 資料生命週期。

可觀察訊號與例子

需要 tombstone 的訊號是資料會被多端複製或同步，而刪除必須確實傳到每一端。常見失敗是離線裝置重新上線後，把本地還在的「已被刪除資料」同步回伺服器 — 對隱私與合規是實質失效。tombstone 也要設保留期：留太短會讓久未上線的端漏接刪除，留太長會讓墓碑本身累積。

設計責任

設計時要決定哪些資料的刪除需要 tombstone、墓碑保留多久、以及何時可以真正清除。保留期要長過預期的最長離線或失聯窗口。observability 要能看到 tombstone 數量與最舊未被所有端確認的刪除。

概念位置

Per-Connection Memory 位在資料庫記憶體模型中、與全域記憶體相對的一側。全域記憶體（例如 Buffer Pool）由所有連線共用、調一次影響全體；per-connection 記憶體每條連線各配一份，調大單份設定會被並發數放大。連線數的上限由 Connection Pool 與資料庫設定共同決定。

可觀察訊號與例子

需要注意 per-connection memory 的訊號是資料庫在尖峰並發時記憶體吃緊、OOM 或被容器重啟，但平時看起來有餘裕。常見的反直覺陷阱是為了讓某個查詢更快而調大 sort / join buffer，結果在高並發時這個「單份」設定乘上幾百條連線，把記憶體撐爆。

設計責任

設計時要把記憶體預算拆成全域與 per-connection 兩部分，並用最大並發連線數去乘 per-connection 設定，確認尖峰仍在容量內。調校順序通常是先把全域記憶體調穩，再針對特定查詢調 session 層設定，並同時限制連線數。observability 要看連線數、記憶體用量與 OOM / swap 訊號。

概念位置

Replication Channel 位在多來源複製的拓撲層。單一來源的複製只有一條流；多來源複製把多條流並存在同一個目標資料庫上，每條就是一個 channel。channel 是隔離單位：一個來源的 Replication Lag 或錯誤不必然代表其他來源也有問題，GTID 之類的識別機制讓各 channel 的位置可以分開追蹤。

可觀察訊號與例子

需要 per-channel 視角的訊號是整體 replica 看起來健康、但某個來源的資料就是慢或對不上。只看整體 replica lag 會錯過「哪一個來源卡住」。常見場景是把多個地區或多個服務的資料庫匯總到一個分析庫，其中一條 channel 因為網路或 schema 問題落後，其他 channel 正常。

設計責任

設計時要為每條 channel 命名、定義各自的 owner、lag SLO 與錯誤處理策略。監控與告警要做到 per-channel，並讓單一 channel 的故障可以只停那一條、不影響其他來源。observability 要能分開看每條 channel 的位置、延遲與錯誤。

概念位置

Vendor Lock-In 位在選型決策的長期成本面。它本身是風險概念，Provider Adapter 與 Integration Adapter 則是緩解它的設計手段 — 把供應商特定的介面包在 adapter 後面，讓 domain 程式碼不直接依賴它。退出時的搬遷要接回 Migration。

可觀察訊號與例子

需要正視 vendor lock-in 的訊號是供應商特定的 driver API、查詢語法或資料格式出現在 domain 邏輯裡。低採用成本的產品（特別是 edge 或 serverless 類）常把成本藏在退出端：接的時候很快，要換的時候發現整個 codebase 都綁住了。一個務實的檢查是「能不能說清楚退出路徑」。

設計責任

設計時要把供應商特定的介面收斂到 adapter 層，並明確記錄退出路徑：要換掉這個供應商，需要動哪些地方。對關鍵依賴，退出路徑應該被實際演練過，而不是只存在文件上。是否接受某個 lock-in 是有效的決策，前提是在採用當下就把成本看清楚。

概念位置

Corruption Recovery 位在事故處理流程中、針對「資料本身壞了」這一類事故。它和一般 incident response 共用 Evidence Package、RCA 的紀律，但多一個前置判斷：儲存層損毀與應用層寫錯的修法不同，前者要還原、後者要修資料也要修程式。

可觀察訊號與例子

需要 corruption recovery 流程的訊號是讀取時出現 checksum 錯誤、結構異常或資料明顯不合理。一個常見的處置錯誤是在疑似損毀的檔案上直接跑修復或 vacuum — 那可能把還能搶救的狀態也蓋掉。正確的第一步是先複製一份原始損毀檔案，保留它當證據與還原素材。

設計責任

設計時要定義損毀的偵測訊號、第一步的證據保全動作，以及修復與還原的決策分支。要事先確認 backup 與還原機制本身可用，否則損毀事故發生時沒有退路。observability 要能盡早偵測 corruption 訊號，把它和一般錯誤分開。

概念位置

Buffer Pool 位在資料庫的儲存與運算之間。MySQL 的 InnoDB buffer pool、PostgreSQL 的 shared buffers 都是同一個概念 — 磁碟頁的記憶體快取。它的更新搭配 Write-Ahead Log：變更先發生在 buffer pool 的頁面上、寫入 WAL，再由 checkpoint 落回磁碟。容量不足時要決定哪些頁被換出，接回 Eviction。

可觀察訊號與例子

觀察 buffer pool 的關鍵指標是命中率：命中率高代表多數讀取走記憶體，命中率掉代表查詢開始打磁碟、延遲上升。常見場景是資料量成長超過 buffer pool 大小，熱資料放不下、頁面頻繁換進換出，查詢延遲整體升高。這時要評估加大 buffer pool 或縮小工作集。

設計責任

設計時要讓 buffer pool 大小和熱資料工作集、機器記憶體與 per-connection 記憶體預算一起規劃。buffer pool 調大會擠壓其他記憶體用途，要留餘裕給連線與作業系統。observability 要看命中率、換頁速率與 dirty page 比例。

概念位置

GTID 位在複製拓撲的進度標記層。沒有 GTID 時，replica 的進度是「primary 的 binlog 檔加位移」，這個座標換一台 primary 就失效；GTID 用交易本身的識別碼當座標，跨機器仍成立。它讓 Failover 後 replica 能自動找到接續點，也讓 Replication Lag 可以用「落後幾個交易」表達。

可觀察訊號與例子

需要 GTID 的訊號是拓撲會變動：會做故障切換、會加減 replica、會調整複製鏈。用實體 log 位置時，每次換 primary 都要手動換算每個 replica 的接續點，容易出錯；GTID 讓 replica 指向新 primary 後自動續傳。CDC 工具也常用 GTID 當位置標記，讓 consumer 斷線重連後既不漏事件也不重複。

設計責任

設計時要在拓撲全體一致地啟用 GTID，並讓故障切換、CDC consumer 與備援流程都以 GTID 為位置基準。要監控每個 replica 與 consumer 已套用的 GTID 集合，據此判斷延遲與缺口。observability 要能看到 GTID 落後量與是否有 gap。

概念位置

Point-in-Time Recovery 位在備份還原機制中、比「還原到最近備份」更精細的一端。RPO 與 RTO 是還原的目標（可接受的資料損失與停機時間），PITR 是達成這些目標的機制：base backup 決定起點、持續歸檔的變更日誌決定能還原到多近的時間點。它和 Rollback Strategy 一起構成事故的資料復原能力。

可觀察訊號與例子

需要 PITR 的訊號是事故型態包含「某個時間點之後的資料被汙染」 — 誤刪、錯誤的批次更新、應用 bug 寫壞資料。只有定期備份時，還原會把備份之後的正常資料一起丟掉；PITR 讓還原點可以精準停在汙染發生前。常見的隱性風險是變更日誌歸檔斷掉，PITR 的可還原窗口其實有缺口卻沒被發現。

設計責任

設計時要確認 base backup 頻率、變更日誌的持續歸檔、以及可還原窗口的長度。PITR 要定期演練 — 真正跑一次還原到指定時間點，才能確認備份與日誌都完整、RTO 在預期內。observability 要監控日誌歸檔是否連續、最舊可還原時間點是否符合 RPO。

概念位置

Outbound tunnel 位在本機進程與公網之間，取代傳統的 port-forward 或 load balancer 入口。常與 TLS / mTLS 搭配保護隧道內的傳輸安全，認證則疊在 tunnel 之後由 authentication middleware 處理。

常見實作包括 cloudflared（綁 Cloudflare 邊緣）和 Tailscale（WireGuard mesh VPN）。隧道網址是位址、不是密碼 — 認證必須疊在 tunnel 之後。

深入：5.10 Outbound Tunnel 入口與生命週期。選型案例：7.C11 Tailscale vs Cloudflare Tunnel。

概念位置

Type Affinity 位在 SQLite 的資料模型核心，和嚴格靜態型別的資料庫相對。多數關聯式資料庫的欄位型別是硬約束，存錯型別會被拒絕；SQLite 的欄位有 type affinity，值會被儘量依 affinity 轉換、也允許存入不同 storage class。它和 Document Store 的彈性 schema 是不同來源的彈性 — 一個是型別寬鬆、一個是結構寬鬆。

可觀察訊號與例子

需要理解 type affinity 的訊號是查詢結果的型別或排序不如預期，或同一欄位混進了數字與字串。常見場景是把數字以字串存入，比較與排序就按字串規則跑；或預期欄位是整數、實際存進了文字。SQLite 的 STRICT table 可以把欄位改回硬約束，讓行為更接近傳統資料庫。

設計責任

設計 schema 時要清楚每個欄位的 type affinity、以及值會如何被轉換。需要嚴格型別保證時，要明確選用 STRICT table 或在應用層驗證。測試 fixture 要涵蓋型別邊界，避免「本機測試剛好都存對型別」掩蓋問題。

概念位置

Distributed lock 處於分散式協調控制層、底層通常依賴 consensus protocol。常見實作載體：

• Redis SET NX + EX：簡單 lease lock、Redlock 算法嘗試強化但仍有爭議
• ZooKeeper / Etcd / Consul：consensus 底層、提供強一致性保證、適合長期鎖
• 資料庫層：PostgreSQL advisory lock、MySQL GET_LOCK() — 跟業務 transaction 同源、但跟 DB primary 綁定

可觀察訊號與例子

典型使用情境包含分散式 cache build（cache miss 時讓單一 process 打 origin、配合 cache stampede 防護）、migration / cleanup job 確保單一 instance 執行、確保兩個 worker 處理不同訂單。實測 Redis lock acquire latency 毫秒級、Etcd / ZK 跨 region 可達 10-50ms — 高頻短鎖通常改用 partition / sharding、是更省 lock 的設計。

設計責任

Fencing token 是必備設計 — 用單調遞增 token 在舊 holder 跟新 holder 並存時、讓資源側拒絕舊 holder 的寫入、防範 clock drift 或 long GC pause 導致的隱性鎖失效。Renew loop 要在 background 確認 renew 成功、若 network 卡住未及時拋錯、process 會自信操作其租約已失效的資源。Lease 期間應縮短 critical section、保持操作時間遠小於 lease timeout。

概念位置

Connection pooler 在 DB topology 中是「應用層跟 DB 之間的 multiplexer 層」、跟 connection pool 是不同層。常見實作：

• PgBouncer（PostgreSQL）：輕量 single-process、三種 pool_mode（session / transaction / statement）
• AWS RDS Proxy（PostgreSQL / MySQL）：managed 版本、整合 IAM auth、failover 加速
• ProxySQL（MySQL）：規則型 routing + connection pooling + query rewriting
• PgCat（PostgreSQL）：Rust 寫的 PgBouncer 替代、支援 sharding

PgBouncer 的 pool_mode 是核心配置：session mode 嚴格說屬 connection caching（單 client 跟 backend 1:1 綁定整個 session）；transaction mode 是多數場景的 default、但限於不依賴 transaction-scoped state 的應用（SET LOCAL、prepared statement、temp table 在 transaction mode 下會丟失）；statement mode 限於純無狀態 query workload、極少用。

可觀察訊號與例子

該裝 pooler 的訊號：應用層機器數 ≥ 20、每臺機器連線數 ≥ 10、DB max_connections 使用率 ≥ 70%、P99 connection wait time 升高。pg_stat_activity 顯示大量 idle 連線是裝 pooler 的明確指標。中型 PostgreSQL 服務裝 PgBouncer 後、DB 連線數常從 1000+ 壓到 50-100。

設計責任

選 PgBouncer 自管要付 HA / failover / 監控的運維成本；選 RDS Proxy 換掉運維、付 per vCPU 計價。Transaction mode 配置前要 audit ORM / driver 行為 — JDBC / asyncpg 的 default prepared statement 跟 transaction mode 衝突、要明示配置 protocol-level prepared statement 或改寫成 inline parameter。Pooler 解的是連線數放大、N+1 query 屬另一層議題 — 兩個問題正交、各自要解。

概念位置

Strangler Fig 處於系統演進的策略層、是組合多種技術的執行框架。完整執行需要四階段：邊界冷凍 + Adapter 抽出（在 monolith 內封 interface）、新服務 + dual write 雙寫期（並驗證對賬）、切流（讀路徑逐步遷移、按 user ID hash / endpoint / dark launch 分流）、寫路徑遷移 + Monolith 退役（寫路徑切到新服務、舊系統 read-only、最後下架）。

階段 4 是 point of no return — 過了寫路徑切換、新服務累積寫入、回 monolith 要 backfill 成本指數成長。

可觀察訊號與例子

大型 monolith 重寫、microservice 拆分、資料庫遷移、第三方 SaaS 換家都用 strangler。完整四階段通常 3-12 個月、雙寫期 1-4 週收斂、切流期 4-12 週逐步推進。Routing layer（API gateway / proxy / feature flag）是核心基礎設施、決定每個 request 走新或舊、出問題能瞬間切回。

設計責任

每階段都要有明示的回退條件跟成本評估 — 階段 1-3 回退代價低、階段 4 之後成本指數成長、要把 monolith 下架時點延後到「確信回退已罕見」、寧可多保留 monolith 1-2 個月。Monolith 下架前用 access log audit 確認真實流量為 0、確保 batch job / report / 內部 tool 都已切換。觀察期是硬要求 — 讀切完後至少 2 週觀察、確認穩定再進階段 4。

概念位置

Modular monolith 處於系統架構演進的「中段」位置、跟 cell-based architecture 沿不同維度拆分。模組化的具體做法包含：每個模組對外公開的 API 用 interface / port 定義、其他模組只能透過 interface 互動；每個模組擁有自己的 table / schema、跨模組查詢走 interface（取代直接 join）；用 lint rule / build tool 強制 dependency graph 是 DAG；模組可獨立 build / test、最終 deploy 仍是 monolithic。

可觀察訊號與例子

適合採用的訊號：業務複雜但團隊規模 5-30 人、部署複雜度敏感（不想維護多服務 ops）、流量 / 團隊 / 變更頻率邊界尚未強到需要拆服務、想為未來拆分做準備。Shopify 在 Rails monolith 內維持 component-based 邊界、Stack Overflow 用單一 ASP.NET monolith 服務全球流量、Basecamp 拒絕 microservice 並 ship Modular Monolith 為長期 endgame。

設計責任

維持模組邊界需要團隊紀律 — 聲稱模組化但實際 import 散落各處、就退化成普通 monolith。要在 CI 強制 dependency 方向、用工具補位 review 自律。早期團隊（3 人以下）強迫每個 feature 都用嚴格 interface、會增加實作摩擦但無收益。當多團隊發布節奏完全不同、或流量 / 資源需求差距大、就到強制拆服務時機、應該主動往 microservice 推進。

概念位置

Cardinality explosion 處於 SQL query 設計的「結果集大小判讀」維度、跟 keyset pagination 都是大表查詢反模式修法。常見成因：多對多 join 缺 filter（100 訂單 × 10 item × 5 tag × 5 評論 = 25000 行）、誤用 CROSS JOIN（漏 JOIN 條件、結果是 N × M 笛卡兒積）、遞迴 CTE 缺終止條件（可能跑出百萬行）。

本卡專指 query result-set 行數爆、跟 metric cardinality（time-series 維度爆）是兩個獨立議題、各自獨立成卡。

可觀察訊號與例子

業務上預期回 100 行、實際拿到 10000+ 行；EXPLAIN 估計 rows 跟實際表大小有數量級落差；應用層記憶體用量隨流量線性升高、但 QPS 增速明顯低於記憶體增速；同樣的 query 在小資料量正常、大資料量 query 變慢且記憶體爆。電商訂單列表頁、報表查詢、後台搜尋是高發場景。

設計責任

修法方向：拆 query（先拿主資源、再用 IN 條件批次取相關資源、從 join 改成 N+1 但 N 可控）；用 EXISTS / 半連接取代 JOIN（只判斷存在性的場景、WHERE EXISTS (...) 比 join 便宜）；明確 LIMIT（大資料量 query 強制加 limit）；重新評估資料模型（頻繁出現代表表關係設計過度正規化）。CI 加 query result size middleware、超過閾值觸發 review 比事後從 slow log 找問題早。

概念位置

Keyset pagination 處於 SQL query 設計的「pagination 策略」維度、跟 query cardinality explosion 是 sibling 反模式修法。對比：

可觀察訊號與例子

該採用的訊號：排序欄位是 indexed + unique（或加 tiebreaker 確保唯一）、使用者操作是「逐頁前進」（next / load more）、大表（百萬 row 以上）需要分頁。Twitter timeline、Slack 訊息歷史、GitHub commit 列表都用 keyset。實測大表 deep pagination 場景 keyset 比 OFFSET 快數百倍 — OFFSET 100000 的 query 從秒級降到毫秒級。

設計責任

排序欄位若是非 unique（如 created_at）、用 (created_at, id) 複合條件確保穩定 — 缺 tiebreaker 時、重複值翻頁會跳過或重複資料。Cursor 編碼成 opaque token 給 client、避免暴露內部 ID 結構（也方便未來改 cursor 內容）。對「插入 / 刪除中翻頁」的行為比 OFFSET 穩定（OFFSET 在這類場景容易跳過或重複）。表小於 10000 行時 OFFSET 也快、保持簡單即可。Google 搜尋結果頁那種「跳到第 N 頁」需求要回到 OFFSET 或考慮重新設計使用者操作。

概念位置

Cache tag purge 處於 CDN / cache 失效策略的「批量失效機制」層、是 cache invalidation 的執行手段。常見 vendor 實作：Fastly Cache Tag（Surrogate-Key header、purge 用 POST /service/.../purge/<tag>）、Cloudflare Cache Tag（Enterprise plan、用 Cache-Tag header）、Akamai Surrogate Key、Varnish（用 X-Cache-Tag header + ban-list）。

CDN 用 cache key（通常是 URL + Vary header）做快取存取。批量失效的三條路是：逐個 URL purge（拿到所有受影響 URL 清單）、wildcard purge（粗、容易誤傷）、tag purge（寫入時就標 tag、失效時用 tag 觸發、精準批量）。tag purge 的優勢是失效範圍在寫入時就規劃好、屬「寫入時規劃」型 invalidation、跟 wildcard 的「事後猜」型對比。

可觀察訊號與例子

電商商品頁、相關搜尋、推薦 widget 都帶 product:123 tag、商品下架時 purge product:123 一次清乾淨；新聞文章 + tag page + author page + RSS 都帶 article:456 tag、文章更新時批量失效相關頁；CMS 模組更新時、所有 reference 該模組的頁面用 template:hero-v2 tag 一次清。實測大型內容系統一次 tag purge 可影響數萬 cache entry、比逐個 purge 快數量級。

設計責任

Tag 粒度設計要在兩端之間取捨：tag 太粗（所有頁面都帶 site:main tag、每次小更新都全站 purge）、tag 太細（每個資源獨立 tag、batch purge 需要 enumerate 所有 tag、退化成逐個 purge）。Vendor 對 tag 數量、tag 長度、purge API rate 都有上限、要事前 audit。跨服務 tag 設計要同步 — 若 CDN 有 tag、應用層快取缺對應機制、CDN purge 後應用層仍 stale、會回填到 CDN。兩層失效要設計成同步協議、視為單一 invalidation pipeline。

概念位置

Cell-based architecture 處於系統架構的「失敗隔離」維度、跟 database sharding 同概念但不同層級（sharding 切資料、cell 切完整 stack）。常見 cell 切分軸：按地理 region（AWS 把每個 region 視為獨立 cell）、按 tenant（multi-tenant SaaS 把大客戶各放獨立 cell）、按 user shard（user ID hash 分到 N 個 cell）、按業務 vertical（DoorDash dispatch / payment / merchant 各 cell）。Cell-based 跟 microservice 可以組合：每個 cell 內部用 microservice、跨 cell 也用 microservice 通訊、但 cell 邊界是故障隔離的硬邊界。

可觀察訊號與例子

適合採用的訊號：規模到「全站事故代價」遠超「N 個 cell 維運成本」（通常每 cell 服務 10 萬+ 使用者才划算）、業務本質支援使用者分群、合規要求資料 / 流量地理隔離。AWS 用 cell 控制 region 級別的事故影響（每個 region 是獨立 cell）、Slack 用 cell 隔離大客戶事故、DoorDash 用 cell 切 dispatch / payment 業務 vertical。

設計責任

Cell 路由層（API gateway / DNS / 負載均衡）決定 request 進哪個 cell、路由邏輯限於單 cell 內 — 防範 cell 間隱式依賴。資料邊界硬切：cell A 的資料庫跟 cell B 完全分離、跨 cell 查詢走標準 API。每 cell 獨立 deploy、rollout 一次只動一個 cell、出問題影響範圍可控。常見失敗：某個 shared service（如 user auth）所有 cell 都打、變成跨 cell 故障的單點 — 真正的 cell-based 連 auth 也要每 cell 獨立或設計成 read-only cache。

概念位置

Freshness token 出現在「application 在 DB 前面加 cache、但 cache 跟 DB 不同步」的場景。跟 Session Consistency 區分：後者是 DB 內部的 causal session、保證同一 session 看得到自己剛寫的；freshness token 是跨層協議、把「保證讀到自己剛寫的」從 DB 內延伸到包含 cache 的整條 read path。跟 Stale Read 是症狀與防護機制的對應 — stale read 是現象、freshness token 是用版本門檻防止它。跟 Cache Invalidation 互補 — 後者由 write 端 push 失效、freshness token 由 read 端 pull 版本檢查、兩者可同時部署。

可觀察訊號與例子

需要 freshness token 的訊號是「DB 寫成功、user 立刻 read、cache 還回舊資料」。9.C36 Coinbase MongoDB 揭露具體機制：在 MongoDB + Memcached 三層架構下、users 服務直接撐 1.5M reads/sec（含 cache、users 服務應用層觀察口徑）。write 成功時 DB 返回 token（含 OCC version / clusterTime）、client 後續 read 帶 token、server 保證返回 ≥ token 版本、必要時 bypass cache 直接打 DB。

設計責任

設計時要先區分 token 的 語意層級 — 是 application 自行管理（如 Coinbase 自建協議、把 version 寫進 token）、還是 SDK 內建（如 Cosmos DB session token 自動跨 service 傳遞）。若同時部署多種 cache 層（CDN / application cache / DB read replica）、token 要能穿透所有層、否則最弱的一層會破壞保證。Token 過期或不可用時的 fallback 行為（bypass cache 直接讀 primary）要明示寫進設計、不能讓 user 在 token 失效時悄悄讀到舊資料。

概念位置

Leaseholder 出現在 CockroachDB / Spanner 等 distributed SQL 架構、跟 Consensus Protocol 是抽象與落地的對應 — Raft / Paxos 是通用 consensus 機制、leaseholder 是 distributed SQL 把它落地成 per-range 的 entry point。跟 Hot Partition 對照：KV 系統的 hot partition 是物理 partition 流量集中、distributed SQL 是 leaseholder 集中在某節點、機制不同但容量影響類似。跟 Single Writer Model 區分：後者是 cluster-level 只有單一 primary 寫入、leaseholder 是 range-level 的 single writer、cluster 內每個 range 可以分散到不同節點。

可觀察訊號與例子

需要 leaseholder 判讀的訊號是「整體 cluster CPU 不高、但某節點 p99 latency 飆 + 寫入 throughput 卡住」。9.C39 DoorDash CockroachDB 揭露 Aurora Postgres 撞牆後遷到 CockroachDB、寫入分散到 leaseholder 跟 Raft replica；9.C40 Netflix CockroachDB 揭露 380+ cluster / 最大單區 60 nodes 規模、leaseholder placement 跟 locality config 直接決定 cross-region latency。

設計責任

設計時要主動把 leaseholder 分布納入 capacity planning — 不是只看 cluster 總 CPU、要看每個節點承擔多少 leaseholder。lease transfer（rebalance、節點 drain、failover）會引發短期 p99 spike、要寫進變更窗口跟 rollback 觀測點。region survival 配置下、voting replica 跨 region 強制提高 write latency、leaseholder placement 跟 locality tag 一致時才能拿到本地 read 紅利、否則跨 region 多跑一趟 RTT。

概念位置

Range sharding 出現在 CockroachDB / Spanner 等 distributed SQL、跟 Partition 必須區分 — partition 卡承擔事件流 / KV 風格的 hash partition 語意、range sharding 是 distributed SQL 系統內透明的 range-based 切分、兩者語意不同。跟 Database Sharding 區分：後者是 application-level 由開發者選 shard key 跟設計 routing、range sharding 是系統自動 split / merge 不需要 shard key。跟 Table Partitioning 區分：PostgreSQL declarative partition 是 single-node table 內的 partition、range sharding 是跨節點分散 + consensus 一起的機制。

可觀察訊號與例子

需要 range sharding 概念的訊號是「設計 distributed SQL schema 時、誤把 KV 的 shard key 思維搬過來」。9.C40 Netflix CockroachDB 揭露 range 預設 ~512MB 自動 split 的機制：380+ cluster / 最大單區 60 nodes / 26.5 TB、不需要 application 端做 shard 設計。9.C10 Spanner 也用類似機制、跟 interleaved table 配合做 parent-child 物理 co-location。

設計責任

設計時不要把 KV partition key 設計的直覺套到 range sharding — 在 range sharding 下、hot range 仍會發生（連續寫入 monotonic key 例如 timestamp 會集中到同一 range）、但解法不是設 shard key、是讓 primary key 有 entropy（例如改用 UUID 或加 hash prefix）。range split 雖然自動、但 split 過程是 ops event、會引發短期 p99 spike、變更窗口要避開。多 region 部署下、range 的 replica placement 由 locality config 決定、預設不會自動把 replica 放到合規 region、要主動配置。

概念位置

HLC 出現在 CockroachDB 等不依賴專用硬體的 distributed SQL、跟 TrueTime 是對照關係 — 兩者解同一個 event ordering 問題、HLC 用軟體 + NTP、TrueTime 用 GPS + 原子鐘。跟 External Consistency 互補但不等同：HLC 保證 linearizability、不保證 external consistency；TrueTime 加 commit-wait 才能達 external consistency。跟 Linearizability 緊密相關 — HLC 在 max-offset 契約成立的前提下、cluster 內所有 transaction 仍是 linearizable。

可觀察訊號與例子

需要 HLC 判讀的訊號是「distributed SQL cluster 節點 NTP 異常、寫入路徑開始 panic」。9.C39 DoorDash CockroachDB 跟 9.C40 Netflix CockroachDB 都用 HLC 撐線性化、NTP 是 ops first-class concern。CockroachDB 預設 max-offset 是 500ms、節點時鐘飄超過就自動 panic、不會發出錯誤 commit；HLC 在跨 node RPC 時把 logical counter 同步推進、確保事件因果順序在跨節點仍可推導。

設計責任

選擇 HLC 路徑就要把 NTP / chronyd 維運當成 production-critical — 不是「裝了就好」、要監控時鐘漂移、設 alert 在 max-offset 的一半左右觸發。max-offset 配置過寬（例如改 5s 想避免 panic）會在跨節點交易順序判讀上引入錯誤、不是 ops 「彈性」、是把線性化保證打破。對比 TrueTime 路徑、HLC 不需要付 commit-wait latency tax、但 cross-cloud / on-prem 部署彈性是它的主要 trade-off 動機、不要為了「不付 commit-wait」就選 HLC、要為了部署環境選 HLC、commit-wait 不付只是順帶結果。

概念位置

Commit wait 出現在 Spanner 系列產品、是 TrueTime API 跟 External Consistency 之間的橋接機制 — TrueTime 給帶 ε 不確定區間的時間 API、commit wait 是 用它撐 external consistency 的具體實作。跟 Latency Budget 互補：commit wait 是無法 scale away 的固定 latency 支出、要當設計初期就寫進預算、不是運維後才補。

可觀察訊號與例子

需要 commit wait 判讀的訊號是「Spanner write latency 拆解時、commit_latencies p99 跟 ε 一起平移」。9.C10 Spanner 揭露 commit wait 機制：Spanner 設 s = TT.now().latest 後等 TT.after(s)、wait ≈ 2ε（從拿 s 那刻起算）；ε 通常 1-7ms（Spanner vendor docs / 2012 OSDI 論文揭露範圍、非 case 直接揭露 production 分布）、所以 commit wait 通常落在 2-14ms。voting region 越分散、ε 上限越高、commit wait 越長。

設計責任

設計時要把 commit wait 當成「Spanner 寫入路徑的固定 latency 稅」、不是可優化掉的成本。region layout 決策直接影響 commit wait — voting region 散布越廣、ε 上限越高、commit wait 越長。read-only transaction 可用 exact_staleness / bounded_staleness 避開 commit wait、適合 reporting / analytics；strong consistency read 要付完整 commit wait + quorum cost、要主動分流。把寫入路徑當「等 commit wait → quorum 已 ack」兩段同步來推 SLO、不是只看 quorum latency 就估完。

概念位置

RU 出現在 Cosmos DB 全產品線、跟 Cost Per Request 是抽象與具體實作的對應 — cost-per-request 是通用概念、RU 是 Cosmos DB 把它落地成單一可計量單位。跟 Throughput 區分：後者是 raw 計量（每秒幾筆 / 幾 MB）、RU 是 vendor 抽象、不可直接互換。跟 Workload Model 互補 — workload model 決定 access pattern、access pattern 決定 RU consumption、兩者一起才能估容量。

可觀察訊號與例子

需要 RU 判讀的訊號是「Cosmos DB throttle 在 monthly bill 之前就先出現、team 估容量發現估不出來」。9.C11 Minecraft Earth 揭露對照：1 RU = 1KB strong-consistent read、寫 ~5 RU、複雜 query 數百 RU；100 萬 RU/s 壓測通過（壓測數字、非 production 持續、case 自己警示）。9.C21 ASOS Cosmos DB 跟 9.C30 Microsoft 365 Cosmos DB 揭露 Black Friday 10x 流量下 autoscale 跟不上 throttle、index policy 改動讓 write RU 漲 30%。

設計責任

設計時要把 RU 估算當 工程動作、不是 vendor 廣告數字 — 量單一 query 的 x-ms-request-charge header、不是看 slow query log；改 index policy 影響 RU、但不改 query 速度、改的是 cost。team 從 CPU + IOPS 思維轉到 RU 思維通常需要 4-6 週、selection 評估時不能只比 monthly bill 就做 ROI 結論、思維遷移成本可能高過 vendor 廣告價差。autoscale 跟 provisioned 的選擇要看 burst 形狀跟 hot partition 風險、壓測通過數字不能直接當 production sizing 上界。

概念位置

Follower read 出現在 CockroachDB / Spanner 等跨 region distributed SQL、跟 Stale Read 是現象與機制的對應 — stale read 是症狀、follower read 是 有意設計 換 latency 的機制。跟 Fallback Read 區分：後者是 failure 時的降級路徑、follower read 是常態低 latency 路徑、兩者觸發條件不同。跟 Read Write Split 區分：後者是 application-level 把 read 導到 replica、follower read 是 distributed SQL 系統內機制、application 透明、跟 voting / non-voting replica 配置綁定。

可觀察訊號與例子

需要 follower read 的訊號是「跨 region distributed SQL、read p99 卡在跨 region RTT 上、但業務可容忍秒級 stale」。9.C40 Netflix CockroachDB 揭露 region survival 配置下的 follower read 機制：voting replica 跨 region 參與 commit、non-voting replica 只 serve follower read；REGIONAL BY ROW + SURVIVE REGION FAILURE 配合時、其他 region 有 non-voting replica 提供本地 follower read。9.C10 Spanner 在 SDK 層提供 bounded_staleness(t) 選項、容忍 t 秒、可讀最近的本地 replica。

設計責任

設計時要把 follower read 跟 read 業務分流綁在一起 — strong consistency read（餘額查詢、剛寫完的訂單）走 leaseholder 路徑、容忍 stale 的 read（dashboard / reporting / 風控分析）走 follower read。不要把 follower read 當 failover 機制、它不是 — failover 是 fallback read 的責任。配置 non-voting replica 時要評估 storage cost、每多一個 region 多一份 storage。closed timestamp 推進延遲（通常數秒）就是 follower read 的 staleness 上界、要寫進 SLO、不是「快取秒數可調」。

概念位置

Serialization failure 是跨 vendor 共通協議、不是單一資料庫的機制。CockroachDB（預設 SERIALIZABLE）、Spanner（read-write transaction）、PostgreSQL SSI（opt-in SERIALIZABLE）、Aurora DSQL 都會在偵測衝突時丟 40001。差別在 衝突偵測時機：PostgreSQL SSI 用 predicate lock 在 commit 階段偵測、CockroachDB 用 timestamp ordering + write intent 在衝突當下就 abort、Spanner 用 strict 2PL 在讀寫過程中 detect。對 application 來說、不管哪家、看到的都是同一個 error code、處理方式一致：rollback、backoff、重跑。

跟 Transaction Boundary 一起設計 — transaction body 必須是 冪等可重跑、不能含「呼叫外部 API 扣款」這類無法重做的副作用。

可觀察訊號與例子

需要面對 serialization failure 的訊號是「同一段 application code 在 PostgreSQL READ COMMITTED 上從不失敗、遷到 CockroachDB / Spanner 後 retry rate 突然飆升」、或「serializable cluster 的 hot row 路徑 p99 latency 隨並行度線性惡化」。CockroachDB 從 PostgreSQL READ COMMITTED 遷移時、application 接管 retry contract 是必要工程、Cockroach Labs 官方推薦 SAVEPOINT cockroach_restart 寫法、讓整個 transaction 可以在 ROLLBACK TO SAVEPOINT 後重新進入。Spanner SDK 內建 retry loop、但開發者仍要保證 transaction body 冪等。

設計責任

設計 serializable workload 時必須先寫 retry policy：exponential backoff + jitter 避免 retry storm、max retry 限制避免 user-facing latency 拖垮、retry budget 接 circuit breaker。Application code 要把 transaction body 寫成可重入 — 跨 statement 的 in-memory state、外部 API call、非冪等寫入都要移出 transaction。沒寫 retry loop 等於把 serializable cluster 當 READ COMMITTED 用、衝突就直接拋例外給終端 user。Hot row 場景（同一筆庫存被千人搶）serialization failure 會持續存在、要靠 Database Sharding 或 application-level 排隊解決、不是調大 retry 次數能擋。

概念位置

Composite partition key 在 KV / document DB 的 partition 抽象層運作 — DynamoDB、Cosmos DB、MongoDB sharded cluster 都用同一套思路。隨 composite 方式不同分兩型：random shard（event_id#random(0,N-1)、寫完全分散、讀必須 fan-out 全部 N 個 shard）跟 calculated shard（event_id#hash(user_id) % N、同 user 寫到固定 shard、單 user 讀不 fan-out、跨 user 讀才 fan-out）。Cosmos DB 的 synthetic partition key、MongoDB 的 hashed shard key、DynamoDB 的 write sharding suffix 都是這個概念的 vendor 命名。

跟 partition layout 是分散式 SQL 透明 range 的 Range Sharding 區隔 — 後者不需要 application 操心 key 設計、composite key 是 application-managed 的明確介面。

可觀察訊號與例子

需要 composite partition key 的訊號是「整體 utilization 低、少數 partition WCU / RU 飆到上限、p99 latency 隨單一 logical key 流量線性惡化」。對應案例：DynamoDB 售票場景單一 event_id（一場演唱會）天然集中、composite event_id#shard + random suffix 把 IOPS 從單 partition 1000 WCU 上限拆到 N × 1000；Cosmos DB synthetic key 把 fanout 設 10-100 之間平衡寫分散跟讀成本。MongoDB hashed shard key 則犧牲 range query 換取均勻分散。

設計責任

設計 composite key 必須先 audit 讀寫比例 — 寫密集 + 讀範圍小（單 user 自己的 timeline）適合 calculated shard、讀寫都跨 logical key（全平台 aggregation）random shard 也吃得消；讀密集 + 跨 logical key fan-out 成本爆炸時要回頭重設 shard 數或加 secondary index。fanout 數量是核心參數：太少（< 10）寫入仍可能集中、太多（> 100）讀放大成本壓垮 RU / WCU 預算。Resharding（改 shard 數）成本極高 — 設計階段就要按最壞峰值估 N、留 buffer、寫進 schema 設計文件而不是只寫 application code。

概念位置

Spanner 是 interleaved table 的代表 vendor — CREATE TABLE Order ... INTERLEAVE IN PARENT Customer ON DELETE CASCADE 把 child row 物理黏到 parent row 旁邊。Storage layout 從 [c1, c2, c3, ...] [o1, o2, o3, ...] 變成 [c1, c1.o1, c1.o2, c2, c2.o1, c2.o2, c3, ...] — parent + child JOIN 在同一個 split 完成、不跨 Paxos group、commit wait + Paxos round-trip 只算一份。CockroachDB 的 REGIONAL BY ROW + parent-child placement 是相鄰概念（透過 region locality 達成類似 co-location 效果、但機制不同）。

跟 Transaction Boundary 共軸 — interleaved 讓 transaction boundary 跟 storage boundary對齊、跨 split transaction 大幅減少。

可觀察訊號與例子

適合 interleaved table 的訊號是「access pattern 固定 parent → child、JOIN 頻率高、跨 split JOIN p99 latency 撐不住」。典型情境：customer → orders、user → posts、tenant → records 這類 1:N 強耦合資料。Spanner 文件揭露的硬限要記住：child PK 必須以 parent PK 為 prefix、最深 7 層、ON DELETE 只能 CASCADE 或 NO ACTION（不像 PG FK 有 SET NULL / SET DEFAULT）、一旦建立無法 ALTER 改 interleave — 要改就是 export + recreate + import、不是 ALTER。

設計責任

設計 interleaved table 必須在 schema 階段就 audit access pattern — 哪些 parent-child 該 interleave 在資料量小時容易決定、資料量到 10 億 row 後再改是大工程。child PK prefix 限制意味設計時要把「跟誰 co-locate」當 schema 主軸、不只是 logical 關聯。不適合 interleave 的情境：child 對多個 parent 有 N:M 關係、access pattern 跨 parent aggregation（report 跨所有 customer 算 orders 總和）、parent 跟 child 寫入頻率差異極大（hot parent 拖累 cold child storage）。錯用 interleave 會把 parent 的 hot range 問題擴散到 child、反而比獨立表更糟。

概念位置

Data residency 直接決定 multi-region database 的拓樸選擇。Aurora Global Database 用 cross-region async replication、在受監管金融場景反指標 — 因為資料一旦複製到另一 region 就違反合規、不是 SLA 換的事。CockroachDB locality + placement、Spanner regional configuration、DynamoDB region-pinned Global Tables 是 合規吸收層 — 用宣告式 region pinning 把資料邏輯綁在合規邊界內、application code 不需要重寫。AWS Outposts / Azure Stack 是另一條路徑、把雲服務硬體直接部署到合規邊界（例如美國 sportsbook 跨州合規要求運算留州內）。

跟 Blast Radius 共軸 — 合規邊界常剛好等於 blast radius 邊界、但兩者的決策驅動力不同（合規是法規硬限、blast radius 是失敗影響範圍）。

可觀察訊號與例子

需要面對 data residency 的訊號是「monolith 要進歐盟 / 中國 / 巴西市場」、或「金融 / 醫療 / 博弈業要進跨境部署」。對應 case：Standard Chartered Aurora 7 cluster fleet 路徑（銀行業跨國合規邊界、跨市場業務邏輯弱、每市場獨立 cluster 可行）；Hard Rock Wire Act 跨州博弈（跨州統一帳戶 + 跨州 reporting 是核心業務、必須邏輯一個 CockroachDB cluster + locality placement 吸收合規）。同一個 合規 driver、不同 業務需求強度 推出完全相反的拓樸決策。

設計責任

設計受合規驅動的系統時、要先把 residency 規則 寫進 schema 層 / placement policy、不是寫在 application code retry 邏輯。讀者規劃 Aurora migration 不能假設 Global Database 一定可用 — 合規禁止跨境複製時要改用每市場獨立 cluster。判讀軸線：(1) 合規顆粒（跨國 / 跨州 / 跨 AZ）、(2) 跨 boundary 業務邏輯需求強度（強 → distributed SQL locality / 弱 → fleet of independent clusters）、(3) 團隊運維能力（單邏輯 cluster 跨 region vs 多獨立 cluster fleet）。錯把 latency 當主因（例如把 AWS Outposts 當「降低 cross-state latency 工具」）會買到 wrong tool — Outposts 的存在動機是 residency、latency 改善是副作用。

概念位置

Cross-region quorum 跟相鄰卡片有清楚的角色分工 — Quorum 是抽象機制（多數 ack 即可 commit）、Latency Budget 是把跨 region RTT 寫進 SLO 的決策框架、Commit Wait 是 Spanner TrueTime 的另一段獨立延遲、不能混算同一個 latency 數字。

Cross-region quorum 的 latency 由 voting replica 之間的網路 RTT 主導、跟 instance config 強相關：

• Regional（單 region 多 zone）：voting 在同 region 內、quorum RTT < 5ms
• Dual-region（同大陸）：跨大陸內、quorum RTT 10-30ms
• Multi-region（跨洲）：跨大陸或跨洲、quorum RTT 100-200ms

跨洲 100-200ms 是物理光速下界、不是 vendor SLA 不夠好 — Spanner / CockroachDB 同樣硬限。常見誤讀是把這 100-200ms 寫成「Spanner commit wait」、實際 commit wait 是 TrueTime 不確定區間導致的另一段 2-14ms 等待、跟 cross-region quorum 是兩個獨立的物理 cost、不能混用一個 latency 數字解釋兩者。

可觀察訊號與例子

需要面對 cross-region quorum 的訊號是「multi-region distributed SQL 的 write p99 latency 鎖在 100-200ms、不管怎麼 tune client / cache / node size 都壓不下來」。對應情境：Spanner 跨洲 multi-region instance 揭露的工程數量級（依 voting region 配置變化、不是 SLA 承諾）；CockroachDB SURVIVE REGION FAILURE 強制 voting replica 散布到多 region、保 region 級故障 RPO=0 但 commit latency 直接吃跨 region RTT。Application 端的訊號是「跨洲 write 的 p99 跟 single-region 比是 10-20 倍、但 read（透過 Follower Read）p99 接近 single-region」。

設計責任

Cross-region quorum 的 latency 不能 scale away — 設計時要把它當 結構性 latency、不是可優化的瓶頸。判讀 instance config 是必要動作：寫密集 + 不需 region survival 的 workload 應該選 regional config、別硬上 multi-region；真的需要跨 region 強一致時、要把 write latency budget 從 single-region 的 10ms 改成跨洲 100-200ms、跟業務協商 SLO。引用 100-200ms 這條 anchor 做 capacity planning 必須先 audit 自家 instance 是哪種 config、不能套用單一基線。RTO=0 / RPO=0 跨 region 不是免費 — 它的 cost 落在 write latency、不是 dollar、要把這條 cost 寫進 sizing 文件。

概念位置

BaaS 位在交付形態光譜的中段：比全託管平台（Wix、Shopify 類）保留更多應用程式控制權（前端完全自己寫）、比自建少掉整層後端服務。它跟自建世界的 database 與 object storage 提供同類能力、差別在存取模型：自建走「client → 自己的 API → 資料庫」、BaaS 走「client → SDK → 平台資料庫」、授權邏輯從 API 層下沉到平台的安全規則裡。

可觀察訊號與例子

適合 BaaS 的訊號是產品形態為行動 app 或 SPA、後端需求集中在認證、資料同步與推播、且團隊想把後端工程延後。一個行動端的記帳 app、用 Firebase Auth 處理登入、Firestore 存帳目並即時同步多裝置、Cloud Messaging 推提醒 — 整個 MVP 沒有一行自己的後端程式。

撞到邊界的訊號有三類：複雜查詢（跨集合報表在查詢受限的平台資料庫上變成資料複製工程）、成本曲線轉折（讀寫計費隨流量線性成長、高流量下超過自建）、安全規則失控（client 直連模型把全部授權寫進平台的規則語言、規則長到難以測試與 review）。

設計責任

採用 BaaS 時的設計責任是在進場當下記錄退出路徑：資料模型沿平台特性設計（反正規化結構、平台專屬同步語意）、遷出等於重做資料層；認證可攜性要先查證（Firebase Auth 可匯出密碼雜湊、屬於少數友善案例）。授權規則要當成程式碼管理 — 進版本控制、有 review、有測試 — 而不是在 console 上長大。判斷該不該採用、以及何時該遷往自建、屬於交付形態選型的判讀。

概念位置

Serverless 位在運算交付模型的光譜上：比 container 平台更往「平台接管」靠 — container 平台管編排、執行單元仍長駐；serverless 連長駐都交給平台、執行單元隨請求出現與消失。它跟 BaaS 常被併用但責任不同：BaaS 提供現成的後端模組（認證、資料庫）、serverless 提供「自己的程式碼、別人的執行環境」。閒置歸零的特性接回 cold start — 歸零的另一面是喚醒延遲。

可觀察訊號與例子

適合 serverless 的訊號是負載間歇且事件驅動：webhook 接收、圖片上傳後的縮圖處理、定時批次 — 流量為零時費用為零、突發時平台自動拉起。一個報名系統的確認信寄送、每天觸發幾百次、每次跑兩秒：常駐主機為它待命整天是浪費、serverless 按兩秒計費。

撞到邊界的訊號有三類：執行時長上限（長任務被平台切斷）、長連線模型不合（WebSocket 類常駐需求要繞路）、以及計價曲線反轉 — 流量從間歇變成持續高檔後、按請求計費會超過長駐 instance、各家 serverless 資料庫的計價單位差異也直接影響這條曲線的位置。

設計責任

採用 serverless 時的設計責任是把「執行單元隨時消失」當前提：狀態放外部（資料庫、object storage）、本地檔案與記憶體只當單次請求的暫存；冷啟動延遲要量測並決定是否預熱；計價要建立用量模型、設帳單 alert — 按用量計費的服務、失控的迴圈或被打的 endpoint 會直接變成帳單事故。

概念位置

並行期屬於遷移驗證的形態家族：dual write 與 shadow read 適用於寫入路徑可控的自建系統之間、並行期適用於來源系統不可改的情境。驗證手段共用 data reconciliation — 定期比對兩邊的筆數、金額與關鍵彙總；結束點是一段 cutover window、由收斂且穩定的對帳差異率觸發排程。

可觀察訊號與例子

一個跑在託管電商平台上的店、決定遷往自建：webhook 與排程匯出把平台的新訂單持續餵進自建資料庫、對帳 job 每天比對兩邊的訂單數與金額總和、內部報表與客服查詢先改走新系統 — 顧客仍在平台下單、新系統用真實流量驗證資料轉換。健康訊號是對帳差異率逐週收斂並穩定；反向訊號是並行期拖過原定窗口仍未排 cutover — 雙系統維運、平台月費與同步管道的持有成本持續累積、並行是驗證階段、長期共存要當成明確決策而非慣性。

設計責任

進入並行期的設計責任有四件：同步管道的完整性（漏事件直接變成對帳差異、來源限流與重試要先設計）、對帳 job 與差異率門檻（沒有量化門檻就沒有「收斂」可言）、內部流量先行（報表、後台查詢先走新系統、讓驗證涵蓋真實讀取模式）、明確的結束條件 — 差異率達標後排 cutover、或在成本反轉時承認部分共存為長期形態並記錄重評條件。

概念位置

外包深度位在「買 vs 建」決策的下一層：決定了某塊能力要買之後、還要決定買到多深。最淺的 managed 基礎設施只外包維運、schema 與 query 仍是自己的、跟自建世界的 database 共用同一套資料模型控制權；中間的 feature SaaS 透過 Provider Adapter 消費一組 API、整塊能力的內部邏輯交給 vendor；最深的 BaaS bundle 一個 vendor 同時交付多塊能力、用整合當賣點。深度越深、保留的控制權越少、遷出時要拆解的整合面越大。

可觀察訊號與例子

辨識深度看「撞牆時你改得動的邊界在哪」。一個跑在 Aurora 或 Neon 上的服務撞到慢查詢、可以自己加 index、改 schema、重寫 query — 能動的邊界很寬、只有底層硬體與維運落在 vendor 手上、這是 managed 基礎設施（managed 內部還有梯度：受限的 serverless 或 BaaS 內嵌的 Postgres 可能沒有 superuser、裝不了 extension、能動的邊界比一台完整 managed 實例窄）。換成 Auth0 或 Algolia、撞到的是 vendor 沒開放的客製：它的擴展點到哪、邊界就到哪、再過去只能在它之外另搭一層 — 這是 feature SaaS、Auth0、Algolia、Stripe 在 dev-tool 端、Ragic、SurveyCake、Airtable 在同深度的 no-code 端、差別在誰來維護。最深一層撞牆時連邊界都不只一條：Supabase 把 Postgres、Auth、Storage、Realtime 用同一套身分綁在一起、想搬走資料層、得連帶拆掉它跟認證、儲存的接點 — 這是 BaaS bundle。

設計責任

選定外包深度時的設計責任是把深度對應的遷出代價先記進選型結論。managed 基礎設施遷出代價低到中、資料是標準格式、換家主要是搬資料改連線；feature SaaS 中到高、資料模型與業務規則沿 vendor 特性長出來；BaaS bundle 最高、代價落在被同一套整合綁住的能力之間、不在資料量。深度不是越淺越好 — 越深省下的整合與維運越多、bundle 的整合本身就是它的價值；責任是讓「省下多少」與「綁住多深」在同一筆帳上算清、而不是只看其中一邊。判斷一塊能力該外包到哪個深度、屬於能力級買 vs 建的選型判讀。

概念位置

Processing semantics 位在 delivery 與 recovery semantics 之間。投遞語意把訊息交給 consumer，處理語意決定這次處理是否讓系統狀態正確，依賴 idempotency 把重複投遞收斂成一次結果。

可觀察訊號與例子

同樣是 at-least-once 投遞，寄信 consumer 重複會寄出兩封、開 invoice 重複會重複計帳、search index sync 重複則天生冪等。副作用形狀不同，能承受的處理語意就不同。

設計責任

設計時對每個副作用標明能否承受重複、亂序與部分失敗。承受不了的補 idempotency key 或 dedup store，把處理結果穩定在一次。

概念位置

Recovery semantics 接在 processing semantics 之後。處理語意保證單次結果正確，恢復語意保證出錯後能回到正確狀態，依賴 offset、checkpoint 與可控的 replay window。

可觀察訊號與例子

consumer 處理到一半 crash，重啟後從哪個 offset 接續、會不會重做已完成的副作用，由恢復語意決定。能任意 offset replay 的事件流（Kafka）跟 ack 後即刪的工作佇列（RabbitMQ）恢復能力不同。

設計責任

設計時把 replay 範圍、checkpoint 粒度與補償路徑寫進 runbook，並保留驗證證據（replay 前後的計數與抽樣），讓恢復後能確認狀態正確而非只是「跑完了」。

概念位置

Replay window 是 recovery semantics 的具體邊界。它把「可恢復」量化成一段 offset 或時間區間：超出 retention 的事件已被刪除、無法重播，補償就要改走資料庫或上游來源。

可觀察訊號與例子

Kafka 設 7 天 retention，replay window 就是 7 天，第 8 天的錯誤要重算就找不到原始事件；SQS 最長保留 14 天、Pub/Sub 預設 7 天，managed 佇列的 replay window 由保留期上限決定。

設計責任

設計時把 replay window 對齊事故偵測到修復的最長時間。偵測延遲若可能超過 retention，就拉長保留期或在下游留可重算的來源，避免事件已過期才發現要補。

概念位置

Consumer pause 是事故處理的閥門。暫停期間 consumer lag 會上升，但事件多半仍在 replay window 內，前提是暫停時間短於 retention，恢復後可從原 offset 接續。

可觀察訊號與例子

下游資料庫過載時，繼續消費只會放大寫入壓力與重試風暴；暫停消費讓壓力停在 broker，下游恢復後再 resume。毒訊息卡住整個 partition 時，暫停加上把該訊息送 dead-letter queue 比硬重試更快止血。

設計責任

設計時讓消費可被快速暫停與恢復，並把 pause、drain、resume 的決策與時點記進 decision log，避免暫停後忘記恢復造成 lag 無聲累積。

概念位置

Event schema compatibility 是事件契約的演進規則，直接影響 processing semantics：schema 不相容會讓 consumer 解析失敗、變成 poison message。backward 相容讓新 consumer 讀舊事件、forward 相容讓舊 consumer 讀新事件、full 兩者都要。

可觀察訊號與例子

producer 加一個必填欄位但未設預設值，舊 consumer 解析失敗、訊息卡在 partition；改成可選欄位或帶預設值就維持 backward 相容。Kafka 用 Schema Registry enforce compatibility level、Pub/Sub 用 schema enforcement，RabbitMQ 與 NATS 多半靠應用層約定。

設計責任

設計時先定相容性等級再演進 schema：高頻跨服務契約用 full 或 backward、內部單向通訊可放寬。新增欄位帶預設、刪欄位分兩步（先停用再移除），避免一次破壞性改版打掛下游。

概念位置

DLQ drain 接在 dead-letter queue 之後、poison-message quarantine 隔離訊息之後。drain 前要先確認根因已修，否則重送只會再次失敗、訊息又繞回 DLQ。

可觀察訊號與例子

DLQ depth 持續上升代表有未處理的失敗累積；修好 consumer bug 後，用 redrive（SQS）或重新 publish 把 DLQ 訊息送回主 queue 重處理。無法修復的（過期、業務上已失效）則歸檔後刪除，而非放著佔空間。

設計責任

設計時把 drain 當受控操作：先驗根因已解、分批重送、邊送邊看成功率，並把 drain 的時點、批量與結果記進 decision log，避免一次全量重送打垮剛恢復的下游。

概念位置

Poison-message quarantine 是 poison message（現象）與 dead-letter queue（隔離區）之間的機制層。它靠 max delivery / maxReceiveCount 計數，超過門檻就把訊息移出主 queue，後續走 DLQ drain 修復或歸檔。

可觀察訊號與例子

同一訊息 redelivery 次數持續累加而從不成功，就是隔離訊號。SQS 用 redrive policy 的 maxReceiveCount、RabbitMQ 用 DLX + 投遞計數、Kafka 多半在 consumer 端自行計數後送隔離 topic。沒有隔離機制時，一則毒訊息會卡住整個 partition 或 queue。

設計責任

設計時把投遞次數上限設在「足夠容忍暫時性失敗、又不會無限重試」之間，並在隔離時保留原始 payload 與失敗原因，讓後續診斷與 drain 有足夠證據。

概念位置

Fencing token 是 distributed lock 在「鎖可能因 GC 暫停、網路分割而失效」這個固有時序窗口下的補強機制。鎖只負責減少競爭，fencing token 讓下游成為最終仲裁者，與 idempotency 同屬「即使協調層失效，結果仍正確」的防線。 可先對照 Distributed Lock。

可觀察訊號與例子

需要 fencing token 的訊號是「鎖牽涉正確性、雙寫會造成金錢或資料損壞」。節點 A 取得鎖後發生長 GC 暫停、租約到期被 B 接手，A 醒來仍以為持鎖而寫入：A 帶 token 33、B 帶 token 34，下游接受過 34 後就拒絕 33。ZooKeeper 的 zxid、etcd 的 revision、資料庫的版本欄位都可以充當 fencing token。

設計責任

設計時要確認下游有能力驗證 token（記住最大值並拒絕較小者）。下游若無法條件寫入（例如第三方 API），fencing token 無法成立，這時要把互斥下沉到資料層的唯一約束或條件更新。token 的生成要保證取鎖動作本身嚴格遞增，用原子計數器或鎖服務序號實作。

概念位置

Cache penetration 是快取放大面的攻擊向量，與 cache stampede、thundering herd 並列「快取從保護層變成放大層」的失效模式。它的觸發源是惡意或意外的不存在 key 枚舉，主要防護是 negative cache 與回源 rate limit，與 stampede 的 soft-TTL / single-flight 防護路徑不同。 可先對照 Negative Cache。

可觀察訊號與例子

判讀訊號是「大量查詢不存在的 key、回源 QPS 飆但 cache 命中率不變」。攻擊者用不連續的 id、構造的非法 slug 枚舉，每個查詢都 miss、穿透到資料庫。電商商品頁被查詢大量不存在的商品 id，資料庫被迫對每個都做一次「查無此商品」的查詢，快取完全沒擋住。

設計責任

設計時要把不存在的結果也納入快取（negative cache），並對回源路徑加 rate limit 與請求來源限制。判讀時要先區分這是 penetration（不存在的 key 枚舉）還是 stampede（熱門 key 同時失效），兩者防護不同，誤套解法會無效。

概念位置

Negative cache 是 cache penetration 防護的主工具，與 cache hit / miss 的差別是它快取的是「miss 這個結果」而非資料本身。它跟一般快取共用 TTL 機制，但 TTL 策略相反：要短到避免遮擋真實資料、又長到擋住重複穿透。 可先對照 Cache Penetration。

可觀察訊號與例子

需要 negative cache 的訊號是「大量重複查詢同一批不存在的 key、回源被無謂打爆」。把「查無此商品」用很短的 TTL 快取，第二次以後的相同查詢直接命中 negative 項、不再打資料庫。

設計責任

negative cache 自身有代價：真實資料建立後要等 negative 項過期才會被命中，TTL 太長會讓新上架資料短暫不可見。設計時 TTL 要明顯短於正常資料的快取週期，並在資料寫入路徑主動失效對應的 negative 項，避免新資料被「查無」結果遮擋。

概念位置

Visibility timeout 是 ack / nack 在「拉取式佇列」上的一種實作：consumer 沒有顯式長連線，而是靠「取走訊息 + 限時處理 + 刪除確認」三步完成 ack。處理超時等同 nack，訊息回到可見狀態觸發 redelivery，多次後進 dead-letter queue。 可先對照 Redelivery。

可觀察訊號與例子

需要調整 visibility timeout 的訊號是「同一訊息被處理多次、或處理完的訊息仍被重投」。timeout 設太短，慢任務還沒處理完就被重新投遞給別的 consumer 造成重複處理；設太長，crash 的 consumer 持有的訊息要等很久才被接手。SQS 的 visibility timeout 預設 30 秒、可依任務耗時調整，長任務用 ChangeMessageVisibility 動態延長。

設計責任

設計時要把 visibility timeout 對著任務耗時分布校準：明顯長於正常處理時間以避免誤重投，又不能長到讓失效 consumer 的訊息卡住太久。長尾任務用動態延長（heartbeat 式續期），並確認處理是 idempotent，因為 at-least-once 下重複投遞無法完全避免。

概念位置

Exactly-once 是 delivery semantics 的一種，與 at-most-once、at-least-once 並列。真正的 end-to-end exactly-once 需要 broker、producer 與 consumer 在同一套交易邊界內協作（如 Kafka 的 transactional producer + read-committed），成本高且邊界窄。實務上更常用 at-least-once + idempotency 處理 duplicate delivery，把「不重複」的責任放到消費端。 可先對照 Duplicate Delivery。

可觀察訊號與例子

把 exactly-once 當預設目標是常見的過度設計訊號。多數業務（出貨、扣款、通知）真正需要的是「重複處理不造成重複副作用」，這用 idempotency key 就能達成，不需要 broker 層的 exactly-once 承諾。誤把 at-least-once 系統當成 exactly-once 依賴、消費端不做去重，則是反向的危險假設。

設計責任

設計時先問「重複生效的代價是什麼」：可重建投影的事件重複只增加成本、用 at-least-once 即可；會扣款出貨的事件要靠消費端 idempotency 或唯一約束擋重複，而非寄望 broker 的 exactly-once。只有在跨系統交易必須原子、且願意承擔吞吐與複雜度代價時，才採真正的 exactly-once。

概念位置

Admin Endpoint 位在內部網路、身份驗證與授權層之後，和一般 public API 分開管理。 可先對照 Alert Fatigue。

可觀察訊號

系統需要 admin endpoint 的訊號是操作會影響大量使用者、資料完整性或金流狀態，且需要額外稽核與來源限制。

接近真實網路服務的例子

後台修改使用者角色、停用帳號、調整活動規則、匯出敏感報表，都應透過 admin endpoint 完成，並保留 audit log。

設計責任

設計時要定義更嚴格的身份驗證、授權、來源限制、操作追蹤與錯誤回應。Admin Endpoint 的失敗後果通常比 public API 更高。

概念位置

API Contract 位在 client、API Gateway 與 application 之間。當外部呼叫者依賴穩定格式時，就需要這種 contract。

可觀察訊號

系統需要 API contract 的訊號是不同團隊會共同整合，且欄位、錯誤碼或版本變動可能直接影響外部使用者。

接近真實網路服務的例子

查詢訂單、建立付款、更新會員資料或回傳錯誤資訊，都應遵守 API contract，並以 contract test 驗證。

設計責任

API Contract 要定義欄位名稱、必要欄位、預設值、錯誤格式與相容版本。破壞性變更需要受控發布與回復路徑。

概念位置

Authentication Middleware 位在 transport layer 與 handler 之間。它負責把 token、session、signature 或其他身份憑證轉成已驗證的 caller context。 可先對照 API Gateway。

可觀察訊號

系統需要 authentication middleware 的訊號是多數 handler 都要先確認身份，且驗證規則應集中管理。

接近真實網路服務的例子

API Gateway 驗證 bearer token、內部服務驗證 service token、webhook 驗證簽章，都屬於 authentication middleware 的責任範圍。

設計責任

Authentication Middleware 要處理憑證提取、驗證失敗回應、context 寫入與錯誤分類，不應混入業務邏輯。

概念位置

Authorization Middleware 位在 authentication 之後、業務 handler 之前。它依角色、資源或 tenant 來判斷可否操作。 可先對照 Authorization。

可觀察訊號

系統需要 authorization middleware 的訊號是很多 handler 都在重複做權限檢查，且權限規則需要一致。

接近真實網路服務的例子

admin 操作、資源 owner 檢查、tenant boundary 檢查與欄位級權限，都常放在 authorization middleware。

設計責任

Authorization Middleware 要定義決策輸入、拒絕回應、稽核欄位與錯誤分類，不應把 policy 分散到各個 handler。

概念位置

Boundary Contract 位在 client 與 service、service 與 service、程式與平台之間。當兩端都需要依同一份規則運作時，就需要 contract 來避免含糊地帶。 可先對照 Draining。

可觀察訊號

系統需要 boundary contract 的訊號包括：不同團隊共同整合、版本需要相容、欄位變更可能影響下游、健康檢查與接流量條件要明確。

接近真實網路服務的例子

API contract 會定義欄位名稱、必要欄位、錯誤格式與相容版本；deployment contract 會定義 readiness、shutdown、draining 與 resource limit；queue contract 會定義 ack、重試與重複投遞行為；load balancer contract 會定義流量切換、health check 與排空行為。

設計責任

Boundary Contract 設計要清楚定義版本、相容性、破壞性變更、驗證方式與回復流程。若 contract 不穩，應搭配 contract test、Release Gate 與文件化規則。

概念位置

Credential 位在 authentication、authorization、secret management 與 service-to-service access 的交界。 可先對照 Cutover / Switchover。

可觀察訊號

系統需要 credential 管理的訊號包括：多個服務共用高權限帳號、需要定期輪替、需要撤銷、或需要在不同環境使用不同存取權。

接近真實網路服務的例子

登入用 credential 要有過期與撤銷；database credential 要依服務分離；webhook secret 要能驗證來源；內部服務 credential 要配合 mTLS 或 signed request。

設計責任

Credential 設計要包含保存方式、權限範圍、輪替、撤銷、稽核與事故回復。原則上應遵守 least privilege，避免單一 credential 擁有過大權限。

概念位置

Deployment Contract 位在 application、container、Kubernetes、systemd 與 rollout control 之間。 可先對照 Draining。

可觀察訊號

系統需要 deployment contract 的訊號是發版、擴容、回滾或停止流程會影響流量與狀態保存。

接近真實網路服務的例子

readiness、shutdown、draining 與 resource limit 都屬於 deployment contract。實際發版節奏與批次切換則交給 rolling update 或 cutover 類卡片處理。

設計責任

Deployment Contract 要明確定義何時可接流量、何時應停止接流量、資源不足時如何回應，以及變更失敗時如何回復。

概念位置

Diagnostic Endpoint 位在運維系統、負載平衡器、監控工具與 application 之間。它通常不承擔產品功能，而是承擔操作判斷。 可先對照 Health Check。

可觀察訊號

系統需要 diagnostic endpoint 的訊號是平台要判斷服務是否可接流量，或工程師需要快速確認特定狀態，但不想翻 log。

接近真實網路服務的例子

health check、readiness 檢查、liveness 檢查、debug status、版本資訊與依賴健康狀態，都可能透過 diagnostic endpoint 暴露。

設計責任

設計時要限制可見資訊、避免透露敏感設定，並把用途與 public API 明確分開。Diagnostic Endpoint 應優先服務平台決策，而不是人手排障的便利性。

概念位置

Integration Adapter 位在 application port 與外部服務之間。repository adapter、provider adapter、notification adapter 都屬於這個角色。 可先對照 Admin Endpoint。

可觀察訊號

系統需要 integration adapter 的訊號包括：外部系統介面常變、錯誤碼不一致、同一個功能需要支援多個供應商、業務邏輯不應直接耦合外部介面細節。

接近真實網路服務的例子

資料庫 adapter 負責 SQL row mapping 與錯誤轉換；付款 adapter 負責 provider API 與內部訂單狀態對齊；通知 adapter 負責把 domain event 轉成 email、push 或 webhook payload。

設計責任

Integration Adapter 要隔離介面差異、做錯誤分類、保留觀測欄位、避免把業務規則塞進整合層。若 adapter 過厚，應把純轉換和流程控制分開。

概念位置

Internal Endpoint 位在 service discovery、internal network、API Gateway 與 application 之間，並可能受到 Request Routing 影響。它通常依賴封閉網段、服務身份與內部流量控制。

可觀察訊號

系統需要 internal endpoint 的訊號是多個服務之間要交換資料，但不希望這些入口暴露到外部網路。

接近真實網路服務的例子

內部訂單同步、跨服務查詢、background worker 呼叫下游系統，或 control plane 對 service 下發設定，都會使用 internal endpoint。

設計責任

設計時要定義內部網路邊界、授權方式、服務發現與變更時的回復策略。Internal Endpoint 的暴露範圍應比 public API 更嚴格。

概念位置

Load Balancer Contract 位在 application、load balancer、ingress 與 service discovery 之間。 可先對照 Health Check。

可觀察訊號

系統需要 load balancer contract 的訊號是流量分散、rolling update、draining 或 idle timeout 直接影響使用者請求。

接近真實網路服務的例子

health check、readiness、draining 與 idle timeout 都屬於 load balancer contract；sticky session 則是另一種負載分派策略，應獨立理解。

設計責任

Load Balancer Contract 要定義什麼情況可接新流量、什麼情況要排空、切換需要等待多久，以及健康檢查失敗後的處理方式。

概念位置

Message Protocol 位在 producer、broker 與 consumer 之間。它適用於 queue、stream 與事件傳遞。 可先對照 Metric Cardinality。

可觀察訊號

系統需要 message protocol 的訊號是工作離開 request 後仍要被處理，而且需要明確的 schema、重試語意與去重責任。

接近真實網路服務的例子

訂單事件、付款事件、通知事件與分析事件都需要 message protocol。消息格式變更時，producer 與 consumer 都要能解讀版本演進。

設計責任

Message Protocol 要定義欄位結構、版本相容、錯誤處理與重播安全。它與 queue contract 不同，前者偏向資料交換語意，後者偏向交付保證。

概念位置

Notification Adapter 位在 application 與通知渠道之間。它負責把內部事件轉成適合發送的外部 payload。 可先對照 Object Storage。

可觀察訊號

系統需要 notification adapter 的訊號是同一個事件要送到多種通知渠道，且各渠道格式、限制與失敗行為不同。

接近真實網路服務的例子

付款完成後寄送 email、訂單更新後送 push、事件變更後發 webhook，通常都由 notification adapter 負責。

設計責任

Notification Adapter 要處理 payload mapping、模板選擇、渠道限制、發送失敗與重試責任，避免通知細節污染業務流程。

概念位置

Observability Middleware 位在 transport layer 與業務 handler 之間。它通常負責 request id、trace context、log context 與 timing。 可先對照 Offline Catch-up。

可觀察訊號

系統需要 observability middleware 的訊號是很多 handler 都需要相同的追蹤欄位與可查詢上下文。

接近真實網路服務的例子

request id 注入、trace context 傳遞、latency 記錄與結束時的操作 log，都屬於 observability middleware 的責任。

設計責任

Observability Middleware 要穩定傳遞 context、避免打斷 error chain，並讓後續 log、metric、trace 可以共用欄位。

概念位置

Provider Adapter 位在 application 與 payment、notification、storage、identity 等第三方服務之間。 可先對照 Pub/Sub。

可觀察訊號

系統需要 provider adapter 的訊號是同一個功能可能切換供應商，或第三方 API 經常變動、錯誤碼不一致、回應格式不穩定。

接近真實網路服務的例子

付款 provider adapter、簡訊 provider adapter、email provider adapter 都是 provider adapter 的例子。

設計責任

Provider Adapter 要隔離外部 API 差異、標準化錯誤、保留關聯欄位，並確保供應商更換不會直接擾動業務邏輯。

概念位置

Public API Endpoint 位在 client、API Gateway、Request Routing 與 load balancer 之間。它通常是最需要版本穩定、文件清楚與錯誤回應一致的入口。

可觀察訊號

系統需要 public API endpoint 的訊號是產品功能要直接暴露給使用者、合作夥伴或 SDK，且需要清楚的授權、節流與回應格式。

接近真實網路服務的例子

查詢訂單、建立付款、更新會員資料或取得 dashboard 資料，通常都會暴露成 public API endpoint，並搭配 authentication、authorization 與 rate limit。

設計責任

設計時要維持 request / response contract、版本相容、錯誤碼穩定與觀測欄位一致。Public API Endpoint 不應混入管理操作或內部調試責任。

概念位置

Queue Contract 位在 producer、broker 與 consumer 之間。當工作要可靠排隊與重試時，就需要清楚的 contract。 可先對照 Queue Depth。

可觀察訊號

系統需要 queue contract 的訊號是工作可能重試、可能重複投遞，且 consumer 需要知道確認失敗後會發生什麼。

接近真實網路服務的例子

ack / nack、retry、dead-letter、duplicate delivery 與 redelivery 都屬於 queue contract 的範圍。

設計責任

Queue Contract 要定義確認語意、重試策略、重送條件、隔離方式與去重責任，避免 broker 與 consumer 對失敗結果理解不同。

概念位置

Repository Adapter 位在 application 與 database 之間。它處理 row mapping、查詢組合與錯誤轉換。 可先對照 Request ID。

可觀察訊號

系統需要 repository adapter 的訊號是 domain 模型不能直接依賴 SQL 細節，但 application 需要穩定地讀寫正式狀態。

接近真實網路服務的例子

訂單 repository、會員 repository、付款紀錄 repository 都是 repository adapter 的例子。

設計責任

Repository Adapter 要處理資料映射、一致性邊界、錯誤分類與 contract test，避免把 SQL 細節滲透到業務層。

概念位置

Request Middleware 位在 transport layer 與業務 handler 之間。它處理多個 endpoint 共用的橫切關注，而不是單一業務規則本身。 可先對照 API Gateway。

可觀察訊號

系統需要 request middleware 的訊號包括：很多 handler 都在重複驗證、關聯 request id、補 log、做權限檢查或遮罩敏感資料。

接近真實網路服務的例子

API Gateway middleware 可以先驗證 token；Admin Endpoint middleware 可以先做授權與 audit；webhook middleware 可以先驗證 signature 與來源限制。

設計責任

Request Middleware 要定義執行順序、短路條件、context 傳遞與副作用界線。安全、觀測與錯誤處理的 middleware 特別需要穩定，不應把業務流程藏在攔截層。

概念位置

Request/Response Protocol 位在 client、API Gateway、service 與 RPC layer 之間。它適用於同步互動的請求/回應模型。

可觀察訊號

系統需要 request/response protocol 的訊號是呼叫方必須等待結果，且錯誤格式、重試條件與版本相容需要穩定。

接近真實網路服務的例子

HTTP API、gRPC method 與內部 RPC call 都屬於 request/response protocol。這類通訊要明確定義 request schema、response schema 與 error shape。

設計責任

Request/Response Protocol 要定義欄位名稱、必填欄位、錯誤碼、逾時期待與版本演進方式。它討論的是同步互動的約定，transport 細節在其他層處理。

概念位置

Security Middleware 位在 transport layer 與 handler 之間。它處理 rate limit、redaction、來源限制或其他共通防護。 可先對照 Security Misconfiguration。

可觀察訊號

系統需要 security middleware 的訊號是安全控制會影響多個 endpoint，且不應散落在每個 handler 中。

接近真實網路服務的例子

rate limit、來源 IP 限制、敏感資訊遮罩與 webhook replay 防護，都可能由 security middleware 承擔。

設計責任

Security Middleware 要把共通安全策略放在邊界上，並維持穩定的拒絕語意與稽核輸出。

概念位置

Throughput 位在容量、排程與流量控制的交界。queue、broker、stream、load test 與 partitioning 都會直接影響 throughput。 可先對照 Thundering Herd。

可觀察訊號

系統需要 throughput 指標的訊號包括：queue lag 上升、consumer 跟不上 producer、load test 失敗、CPU 或 I/O 長期飽和。

接近真實網路服務的例子

checkout 每分鐘要處理多少訂單、consumer group 每秒可消化多少事件、load balancer 後面每個 instance 的穩定處理量，都是 throughput 問題。

設計責任

Throughput 設計要定義測量單位、瓶頸位置、單節點與整體容量、以及在哪些條件下需要 backpressure、rate limit 或 scale out。

概念位置

Validation Middleware 位在 transport layer 與 handler 之間。它負責共通輸入驗證，而不是 domain 規則本身。 可先對照 WAF。

可觀察訊號

系統需要 validation middleware 的訊號是很多 handler 都要重複檢查格式、必要欄位或基本範圍。

接近真實網路服務的例子

JSON schema 檢查、header 驗證、基本參數完整性與 payload shape 檢查，都適合放在 validation middleware。

設計責任

Validation Middleware 要快速拒絕明顯無效的 request，並把輸入錯誤與 domain 錯誤區分開。

概念位置

Webhook Protocol 位在 external system、HTTP endpoint 與 service 之間。它是外部事件導入的通訊約定。 可先對照 Webhook。

可觀察訊號

系統需要 webhook protocol 的訊號是第三方會主動呼叫服務，而且需要簽章驗證、重放防護與穩定 payload。

接近真實網路服務的例子

付款通知、物流更新、SaaS 事件同步與第三方 callback 都會使用 webhook protocol。呼叫方與接收方都需要知道成功與失敗時的行為。

設計責任

Webhook Protocol 要定義簽章、timestamp、重送、payload schema 與錯誤回應。它應與 public API 分開看待，因為它承擔的是外部推送而不是主動查詢。