本篇與 0.13 操作控制 vertical slice 互補：0.13 走的是 04/06/08 的操作控制閉環（觀測 → 驗證 → 事故 → 回寫），本篇走的是 01/02/03/04 的資料基礎設施鏈（狀態 → 副本 → 事件 → 訊號）。

服務路徑

一次 checkout 的最小路徑：

1client
2  → checkout-api
3    → order-db          (01: 寫入正式狀態)
4    → cache invalidation (02: 失效商品快取)
5    → event publish      (03: 發布 order.created 事件)
6    → telemetry          (04: span / log / metric 記錄)

這條路徑刻意簡化。真實系統可能還有 payment adapter、inventory lock、notification service、search index sync 等環節，但四層串聯的責任分工用最小路徑就能說明。後續章節把各層展開。

第一層：資料庫寫入（01）

Checkout 的正式狀態是訂單紀錄。這筆寫入必須在 transaction boundary 內完成，確保訂單、明細與付款紀錄一起成功或一起失敗。

責任邊界：

• 訂單狀態是 source of truth，快取和事件都是下游副本
• Transaction 範圍盡量小：寫入訂單 + 明細 + outbox record，不在同一個 transaction 裡做外部 API 呼叫
• Schema 需要支援狀態演進：訂單從 pending → paid → shipped 的欄位設計見 1.7 schema migration rollout evidence

失敗判讀：

交接給下一層的資訊：transaction commit 成功後，訂單 ID 與狀態就緒。Outbox record 已寫入同一個 transaction。

第二層：快取失效（02）

訂單成功後，商品庫存或價格的快取副本可能已經過期。快取失效的責任是讓後續讀取拿到正確狀態，同時保護資料庫不被回源壓力打穿。

責任邊界：

• 快取是 可重建副本，資料來源是資料庫的正式狀態。失效後的 cache miss 會回源到資料庫
• 失效策略用 cache aside：寫入後主動 invalidate，下次讀取時 lazy reload
• Invalidation 的順序：先 invalidate 應用層快取（Redis），再考慮是否需要 purge CDN 層（若商品頁有 edge cache）

失敗判讀：

交接給下一層的資訊：快取失效完成（或 TTL 保底）。接下來的事件發布不依賴快取狀態 — 事件內容來自 DB 寫入結果。

第三層：事件發布（03）

訂單寫入後，order.created 事件需要傳遞到下游：通知服務寄信、庫存服務更新、搜尋索引同步、分析管道記錄。這些下游不在 checkout request 內完成，要用非同步傳遞。

責任邊界：

• 事件發布與 DB 寫入的一致性用 outbox pattern：outbox record 在 DB transaction 內寫入，poller 或 CDC 負責把 record 發到 broker
• Broker 保證 at-least-once delivery，consumer 需要做 idempotency 處理
• Event contract（schema、idempotency key、replay window）見 3.7 event contract replay boundary

失敗判讀：

交接給下一層的資訊：事件已發到 broker，每一步（publish、ack、consume、DLQ）都需要觀測訊號。

第四層：觀測訊號（04）

以上三層的每一步都需要被記錄成可查詢的訊號。Checkout 路徑的觀測責任是讓事故判讀者能用同一組 trace ID 串起完整鏈路。

責任邊界：

• Trace context 從 client 一路 propagate 到 consumer，跨 sync（HTTP）與 async（queue）邊界
• Log schema 使用統一欄位：order_id、trace_id、tenant_id、region
• Metrics 覆蓋三組 SLI：checkout latency（p50/p95/p99）、checkout error rate、event publish lag
• Dashboard 把上述三組 SLI 放在同一個 checkout 服務面板
• Evidence package 把查詢、時間窗、資料品質與 owner 打包成可交接證據

失敗判讀：

四層交接總覽

 1┌─────────────┐    commit     ┌──────────────┐
 2│  01 DB      │──────────────→│  02 Cache    │
 3│  order-db   │    ok         │  invalidate  │
 4│  write      │               │  product key │
 5└──────┬──────┘               └──────────────┘
 6       │ outbox
 7       │ record
 8       ▼
 9┌─────────────┐
10│  03 Event   │
11│  publish    │
12│  order.     │
13│  created    │
14└─────────────┘
15       │
16       │ all layers emit
17       ▼
18┌──────────────────────────┐
19│  04 Observability        │
20│  span + log + metric     │
21│  per layer               │
22└──────────────────────────┘

每一層都有明確的失敗判讀與交接資訊。四層合在一起的判讀順序是：先看 04 的 trace 確認斷點在哪一層，再進那一層的失敗訊號表。

跨層失敗場景

單層失敗表只處理各自的責任。跨層失敗需要同時看多組訊號：

DB commit 成功，但快取沒失效且事件沒發出

原因通常是 outbox poller 和 cache invalidation 在同一個 request 內串行、前者失敗後沒做到後者。判讀順序：

1. 04 的 trace 看 checkout span 是否有 error tag
2. 01 的 outbox table 看 pending row 是否堆積
3. 02 的 cache key 是否仍是舊值（TTL 保底正常時可接受）

修正方向：invalidation 和 outbox 解耦 — invalidation 在 DB commit 後同步執行（失敗可 retry），outbox 非同步由 poller 負責。兩者不應互相阻塞。

Event consumer 重複處理造成庫存扣兩次

原因是 consumer 的 idempotency 沒做好，broker redelivery 導致重複副作用。判讀順序：

1. 04 的 consumer span 看 redelivery count
2. 03 的 DLQ 看是否有 poison message
3. 01 的 inventory table 看同一 order_id 是否有多筆扣減

修正方向：回 3.4 consumer design 補 idempotency key 驗證，用 order_id 當去重鍵。

Checkout latency 上升但 DB 和 cache 都正常

原因可能是 outbox poller 或 event publish 在 request path 內同步等待（設計錯誤）。判讀順序：

1. 04 的 checkout span 看 child span 時間分布
2. 確認 event publish 是否在 request 返回前完成（不該）
3. 如果是，回到 03 確認 outbox pattern 是否正確實作（寫 outbox record 應在 DB transaction 內、publish 應由 poller 異步執行）

各模組回讀路由

使用方式

本篇是索引型讀物。讀者第一次讀時順著四層走一遍，建立跨模組的交接心智模型。之後遇到具體問題時，用失敗訊號表定位到對應模組的章節。

已經有某一層經驗的讀者可以從那一層開始讀，看該層與相鄰層的交接欄位是否對齊。資料庫工程師從第一層開始看事件發布的交接；觀測工程師從第四層反推前三層需要哪些欄位。

本篇不處理 payment adapter、inventory lock、notification 等更複雜的分支。這些分支的模式相同 — 確認責任邊界、交接欄位與失敗判讀 — 讀者可以自行延伸。

同一份資料、兩種消費路徑

 1SDK 埋點（event / error / metric / lifecycle）
 2  │
 3  ├── 行為分析路徑 → Monitoring 08
 4  │     消費者：PM / 行銷 / 產品
 5  │     方法：funnel / cohort / attribution / A-B test
 6  │     決策：改 UI、調定價、投廣告
 7  │
 8  └── 訊號治理路徑 → Backend 04
 9        消費者：SRE / platform team / on-call
10        方法：cardinality budget / cost attribution / signal governance
11        決策：降 cardinality、調 sampling、改 alert、產出 evidence

這不是兩套埋點。同一個 button.click event，產品團隊看的是「哪個步驟流失最多使用者」，工程團隊看的是「這個 event 的 cardinality 是否在預算內、ingestion cost 是否合理」。event 相同，切入角度不同。

資料格式的交叉點

Monitoring SDK 送出的事件格式（02 Log Schema）和 Backend 04 的 log schema / OTel event format 有共通欄位：

格式一致性的價值是一份 event 同時餵 BigQuery（行為分析）和 Grafana Loki（訊號查詢）不需要格式轉換。如果兩邊各自定義 schema，同一個 event 要寫兩次 adapter，schema drift 的風險倍增。

資料治理的衝突

同一份資料被兩邊消費時，治理需求會衝突：

這些衝突無法靠「選一邊」解決。行為分析少了歷史資料就看不到趨勢；訊號治理存太多高粒度資料就 cardinality 爆炸。解法是分流。

解法：在 transport 層分流

把 SDK 送出的 event 在 collector 或 pipeline 層分流到不同 backend，各自按需求治理：

Hot path：即時訊號

error 和 metric 類事件即時進入 04 telemetry pipeline（Loki / Prometheus / Tempo），短期 retention（30-90 天），服務 on-call debug 和 incident triage。這條路徑要求秒級延遲、低 cardinality（聚合維度）。

Warm path：行為分析

全部四類事件進入 data warehouse（BigQuery / ClickHouse / Snowflake），長期 retention（年級），服務 funnel、cohort、attribution 和 A/B test。這條路徑接受分鐘級延遲、高粒度（per-user / per-session）。

Cold path：合規留存

audit-level event 進入 archive storage（Cloud Storage / S3 / Glacier），法規要求的年級保留（GDPR 刪除請求、HIPAA 6 年、金融業更長）。這條路徑寫入後幾乎不查詢，查詢時接受小時級延遲。

分流的關鍵設計

分流在 transport 層做，不在 SDK 層做。SDK 統一送出全部 event 到同一個 endpoint，pipeline 按 event type / source / tag 路由到不同 backend。

1SDK → Collector / OTel Collector / Cloud Logging
2         │
3         ├─ [type=error OR type=metric] → Hot path (Loki / Prometheus)
4         ├─ [all events]                → Warm path (BigQuery)
5         └─ [audit=true]               → Cold path (Cloud Storage)

SDK 不需要知道下游有幾個消費者。新增一個消費者（例如新的分析平台）只要在 pipeline 加一條路由，不用改 SDK。

實作考量

分流的實作方式取決於 pipeline 架構：

不論哪種架構，分流後的每條 path 要各自設定 retention、sampling、PII handling 和 cost budget。Hot path 的 cardinality 治理 規則不該影響 warm path 的分析粒度；warm path 的長期保留成本不該擠壓 hot path 的 freshness。

常見誤區

用兩套 SDK 替代分流

在 client 端同時整合行為分析 SDK（Mixpanel）和 error tracking SDK（Sentry），看似分工清楚，實際是兩套 schema、兩份 ingestion cost、兩組 PII 風險面、兩套 consent 管理。同一個 user action 在兩個平台各記一次，但欄位名、timestamp 精度、user identifier 可能不同，跨平台 correlation 困難。

統一 SDK + pipeline 分流的成本通常低於雙 SDK 的整合與治理成本。

Hot path 存全量高粒度

把 per-user / per-session 的完整事件直接灌進 Prometheus 或 Loki，會導致 cardinality 爆炸（4.7 Cardinality 治理）。Hot path 的正確做法是在 pipeline 層做 aggregation 或 relabeling，只保留 service / endpoint / status 等低 cardinality 維度。高粒度資料走 warm path。

Warm path 不做 PII 處理

行為分析需要 user segment，但不需要 PII 原文。warm path 的 ingestion pipeline 應該在寫入 warehouse 前做 PII redaction（hash user_id、truncate IP、strip email）。Monitoring 07 去識別化 的策略同時適用於 hot 和 warm path。

讀者路由