判讀訊號

風險與邊界

把合規當成部署後補強會抬高長期成本。較穩定的做法是在選型時就定義證據鏈、資料邊界與回復順序，避免後續跨模組反覆返工。

下一步路由

先補 4.12 的審計訊號，再用 6.8 定義合規變更門檻。

本章目標

學完本章後，你將能夠：

1. 用需求類型辨識後端服務分類
2. 區分資料儲存、快取、訊息傳遞、觀測與部署平台
3. 判斷一個問題應先進入哪個 backend 模組
4. 避免把所有外部技術都混成同一種「基礎設施」

【觀察】需求會先表現成系統症狀

後端服務選型通常從症狀開始。產品需求或事故描述裡會出現一些可觀察訊號：

這張表是索引。真正的選型要看每個訊號背後的資料生命週期、流量形狀與操作需求。

【判讀】資料長期存在通常先看資料庫

資料庫解決的是「系統承認哪份資料是正式狀態」。如果資料需要長期保存、支援查詢、維持交易一致性、被多個 request 共同讀寫，選型應先進入資料庫與持久化模組。

接近真實網路服務的例子包括：

• 電商訂單需要保存付款狀態、出貨狀態與退款紀錄
• 會員系統需要保存帳號、權限、登入方式與審計資料
• SaaS 產品需要保存 workspace、plan、billing 與使用量

這類問題的核心是 source of truth。快取可以加速讀取，queue 可以延後處理，log 可以協助診斷，但正式狀態仍需要清楚的資料模型與一致性邊界。

下一步可讀：資料庫與持久化。

【判讀】讀取壓力集中通常先看快取

快取解決的是「同一類資料被重複讀取時，如何降低正式資料來源壓力」。如果資料本身已經有 source of truth，但熱門資料導致資料庫或下游 API 壓力過高，選型應先進入快取與 Redis 模組。

接近真實網路服務的例子包括：

• 商品詳情頁被大量瀏覽，但商品資料變更頻率低
• 使用者權限或 Feature Flag 每個 request 都要查
• 即時服務需要快速查詢 client presence 或 topic 訂閱狀態

這類問題的核心是讀取路徑與失效策略。快取要回答資料何時過期、何時更新、下游失敗時如何回應、cache miss 尖峰如何保護系統。

下一步可讀：快取與 Redis。

【判讀】工作跨出 request 通常先看訊息傳遞

訊息佇列解決的是「工作離開目前 process 或 request 後，如何可靠地被處理」。如果一個 request 需要觸發後續工作、等待外部系統、重試、批次處理或跨服務通知，選型應先進入訊息佇列與事件傳遞模組。

接近真實網路服務的例子包括：

• 付款成功後要寄信、更新 CRM、發送推播與建立出貨任務
• 使用者上傳影片後要轉檔、產生縮圖與通知完成
• IoT 裝置上報資料後要清洗、聚合與觸發告警

這類問題的核心是 delivery semantics。系統要決定是否需要持久化、是否允許重複投遞、失敗是否重試、consumer 如何水平擴展。

下一步可讀：訊息佇列與事件傳遞。

【判讀】看不見系統行為通常先看觀測平台

可觀測性平台解決的是「服務發生什麼、為什麼發生、影響範圍多大」。如果事故發生後只能看單機 log，無法串起 request、事件、下游依賴與容量趨勢，選型應先進入可觀測性模組。

接近真實網路服務的例子包括：

• API 偶爾變慢，但無法判斷是資料庫、外部 API 還是部署節點問題
• queue lag 上升，但不知道 producer 變快還是 consumer 變慢
• WebSocket client 斷線增加，但缺少連線生命週期與地區資訊

這類問題的核心是操作訊號。log、metric、trace、dashboard 與 alert 需要共用欄位與關聯方式，才能讓工程師從症狀回到原因。

下一步可讀：可觀測性平台。

【判讀】服務交付不穩通常先看部署平台

部署平台解決的是「服務如何被啟動、更新、擴容、接流量與停止」。如果問題集中在 rolling update、liveness、load balancer、service registry、service discovery、container image 或資源限制，選型應先進入部署平台與網路入口模組。

接近真實網路服務的例子包括：

• 發版時部分 request 失敗，舊 pod 和新 pod 切換不穩
• 服務需要水平擴展，但 client 不知道該連到哪個 instance
• shutdown 時仍有背景工作或長連線尚未清理

這類問題的核心是平台合約。程式要提供 health、readiness、shutdown 與資源使用訊號；平台要提供流量入口、排程、發版與回滾能力。

下一步可讀：部署平台與網路入口。

進入規模成長路線時、能力地圖之外還要看四條額外章節：10.1 服務拆分與邊界判讀 處理「該不該拆服務」、0.19 雲端服務對照地圖 處理「該選哪家 vendor」、9.13 擴展軸與 Stateless 前提 處理「該怎麼擴容」、1.13 應用層查詢反模式 處理「擴容前先優化什麼」。

小結

後端服務選型先從需求類型開始。資料長期存在先看資料庫，讀取壓力集中先看快取，工作跨出 request 先看訊息傳遞，系統行為缺少可見性先看觀測平台，服務交付不穩先看部署平台。分類清楚後，後續產品選型與實作細節才會有正確位置。

判讀訊號

風險與邊界

只追求低延遲而忽略隔離邊界，會在高峰時把單一熱點擴散成全域事故。選型時需要同時定義分流邏輯與分批恢復策略。

下一步路由

把容量假設回寫 6.9，並在 8.14 補多事故協調規則。

本章目標

學完本章後，你將能夠：

1. 區分 source of truth、cache、search index、event log 與 object storage
2. 用資料生命週期判斷儲存服務類型
3. 看懂資料庫與 Redis、搜尋引擎、event store、object storage 的差異
4. 把資料選型轉成可檢查的工程判斷

【觀察】資料類型不同，儲存責任也不同

資料儲存服務的第一個問題是「這份資料扮演什麼責任」。同一份商品資料可以同時出現在 PostgreSQL、Redis、Elasticsearch、event log 與 object storage 裡，但每個位置的責任不同。

這張表是索引。選型時要看資料是否能重建、是否需要一致性、是否要被使用者查詢、是否承擔稽核責任。

【判讀】source of truth 承擔正式狀態

Source of truth 的核心責任是保存系統承認的正式狀態。當資料需要被交易保護、被多個流程共同讀寫、支援一致查詢與長期保存時，應先評估資料庫。

接近真實網路服務的例子包括：

• 訂單狀態：created、paid、shipped、refunded
• 會員帳號：email、password hash、角色、訂閱方案
• 付款紀錄：交易 ID、金額、貨幣、狀態、時間

這類資料的主要風險是寫入一致性。服務要知道誰能改狀態、哪些欄位要一起成功、失敗後如何重試或補償。這些問題通常屬於資料庫與 transaction 邊界。

【判讀】cache 承擔可重建的讀取加速

cache 的核心責任是降低讀取成本。快取資料應該能從 source of truth 或下游服務重建；它的價值在於吸收熱門讀取、降低延遲、保護正式資料來源。

接近真實網路服務的例子包括：

• 商品詳情頁快取商品名稱、價格與庫存摘要
• 使用者 session 或權限摘要
• WebSocket presence 狀態與 topic 訂閱集合

這類資料的主要風險是過期與不一致。服務要知道 cache miss 怎麼處理、TTL 如何設定、資料更新時如何失效、熱門 key 如何保護。

【判讀】search index 承擔查詢體驗

Search index 的核心責任是支援搜尋體驗。當使用者需要全文搜尋、排序、filter、facet、autocomplete 或相關性排序，搜尋索引通常比一般資料庫查詢更合適。

接近真實網路服務的例子包括：

• 電商商品搜尋與分類篩選
• 文件站全文搜尋
• 企業知識庫搜尋與權限過濾

這類資料的主要風險是索引延遲與查詢語意。正式狀態通常仍在資料庫，search index 是為搜尋體驗建立的讀取模型。服務要知道資料更新後多久進索引、搜尋結果是否允許短暫延遲。

【判讀】event log 承擔歷史與重播

Event log 的核心責任是保存已發生的事。當系統需要 audit、replay、補送、狀態重建或跨服務事件傳遞，事件歷史就需要獨立設計。

接近真實網路服務的例子包括：

• 訂單狀態每次改變都要留下 audit log
• 付款成功事件需要被通知、出貨、分析系統各自消費
• 使用者行為事件需要進入分析 pipeline

這類資料的主要風險是順序、重複與 schema 演進。Event log 要說明事件代表哪個 domain fact、如何去重、如何處理舊版本 payload。

【判讀】object storage 承擔大型非結構化資料

Object storage 的核心責任是保存大型 blob。當資料是圖片、影片、PDF、匯出報表、備份檔或模型檔案，儲存服務通常需要 object storage，而正式 metadata 放在資料庫。

接近真實網路服務的例子包括：

• 使用者上傳的大頭貼、附件與影片
• 每日報表匯出的 CSV 或 PDF
• 系統備份、稽核封存與資料匯出檔

這類資料的主要風險是存取權限、生命週期、版本與連結有效性。資料庫保存 object key、owner、狀態與 metadata；object storage 保存實際檔案內容。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入資料儲存實作章節：

1. 每一類資料的責任是否明確（正式狀態、快取、搜尋、事件、檔案）
2. 每一類資料的真實來源是否明確（source of truth 在哪裡）
3. 每一類資料是否定義一致性與延遲容忍度
4. 每一類資料是否定義保留期限與回復方式

下一步建議路由：

• 01-database
• 02-cache-redis

小結

資料儲存選型要先問資料責任。正式狀態進資料庫，可重建讀取資料進快取，搜尋體驗用 search index，歷史與重播用 event log，大型檔案用 object storage。責任分清楚後，同一份業務資料可以出現在多個服務中，但每個服務的位置都能被解釋。

判讀訊號

風險與邊界

將合規需求與 DR 流程分開設計，容易在事故時出現互斥決策。較穩定做法是先定義可恢復資料集合與不可跨境資料集合，再安排回復順序。

下一步路由

先補 4.18 的責任邊界，再在 6.7 驗證回復流程。

本章目標

學完本章後，你將能夠：

1. 區分本地背景工作、broker queue、stream、pub/sub 與 outbox
2. 用投遞保證、重試需求與 fan-out 需求判斷服務類型
3. 看懂 RabbitMQ、Kafka、NATS、Redis Streams 這類工具的選型入口
4. 把非同步設計轉成可檢查的工程判斷

【觀察】非同步需求來自 request 邊界外的工作

非同步處理通常從一個現象開始：某件事適合在 request 結束後繼續做。這可能是因為工作太慢、需要重試、需要多個 consumer、需要跨服務傳遞，或需要在資料庫交易後補送事件。

這張表是索引。選型時要看事件是否能遺失、是否會重複、是否要重播、是否要多個服務各自消費。

【判讀】local worker 承擔 process 內背景工作

Local worker 的核心責任是把工作從 request 等待時間中拆出來，但仍留在同一個 process 裡。當工作可以接受 process 重啟後消失，或上游可以重新觸發，local worker 通常足夠。

接近真實網路服務的例子包括：

• request 完成後寫一筆非關鍵 audit log
• 在同一服務內批次刷新短生命週期快取
• 定期清理 memory repository 裡的過期資料

這類設計的主要風險是生命週期。worker 要能停止、記錄錯誤、控制 queue full，並在 shutdown 時有明確策略。語言教材通常會處理這一層，例如 Go 的 Run(ctx)、in-process channel 與 worker pool。

【判讀】durable queue 承擔可重試工作

Durable queue 的核心責任是讓工作在 process 重啟、暫時失敗或 consumer 下線後仍能被處理。當事件可以延後，但需要可靠送達與重試，應評估 broker queue。

接近真實網路服務的例子包括：

• 付款成功後寄送 email、簡訊與推播
• 上傳影片後排隊轉檔
• 訂單成立後建立出貨任務

這類設計的主要風險是 delivery semantics。服務要決定 ack/nack、retry、dead-letter queue、poison message 與 idempotency。RabbitMQ、NATS JetStream、Redis Streams 都可以承擔部分 durable delivery，但模型不同。

【判讀】stream 承擔可重播事件序列

stream 的核心責任是保存事件序列，讓 consumer 可以依自己的進度讀取。當資料需要 replay、多個 consumer group、offset 或 partition ordering，stream 模型會比單純 queue 更合適。

接近真實網路服務的例子包括：

• 使用者行為事件進入分析 pipeline
• 訂單事件同時給推薦、風控、報表系統消費
• IoT sensor readings 需要持續聚合與回放

這類設計的主要風險是順序、保留期限與 schema 演進。Kafka、Redis Streams、NATS JetStream 都提供不同程度的 stream 能力；選型時要看 throughput、consumer group、保留策略與操作成本。

【判讀】pub/sub 承擔即時 fan-out

Pub/Sub 的核心責任是把訊息即時傳給目前訂閱者。當訊息偏向即時通知，且訂閱者離線後可以透過 offline catch-up 補狀態，pub/sub 通常是好候選。

接近真實網路服務的例子包括：

• WebSocket server 跨節點廣播 topic update
• presence 狀態變更通知在線 client
• dashboard 即時刷新目前任務進度

這類設計的主要風險是 reliability boundary。pub/sub 適合即時 fan-out；若訊息需要 offline catch-up、audit 或 strong reliability，通常還需要 durable queue、event log 或資料庫狀態搭配。

【判讀】outbox 承擔資料寫入與事件補送

outbox 的核心責任是把業務資料寫入和待發事件放進同一個資料庫交易，再由 publisher 補送。當狀態更新成功後必須可靠發布事件，outbox 是常見選型。

接近真實網路服務的例子包括：

• 訂單寫入成功後必須發布 order.created
• 付款狀態更新後必須通知出貨與報表系統
• 帳號停用後必須可靠通知所有安全相關服務

這類設計的主要風險是半成功。outbox 讓事件至少會被發現並補送；consumer 仍需要 idempotency，因為補送與重試可能造成重複投遞。

【判讀】用業務形狀反推 broker 候選

反推的核心責任是把「目前場景需要的吞吐、延遲、保留窗口與操作承擔」轉成 broker 候選、不是從 vendor 規格表挑工具。先決定需求形狀、再對齊量級訊號、最後才挑工具。

接近真實網路服務的反推路徑：

• 感測器一秒上報幾百筆、可接受偶發遺失、後端只需即時聚合 → broker 候選是 MQTT broker / NATS、量級訊號 sub-ms 延遲 + 萬到十萬 msg/sec
• 訂單事件需要多個下游服務各自 replay、保留 7 天以上 → broker 候選是 Kafka / Pulsar、量級訊號 partition 化吞吐 + retention 天 / 週 / 月可設
• 寄信、轉檔等可重試任務、不要遺失但允許短暫延遲 → broker 候選是 RabbitMQ / SQS、量級訊號萬級 msg/sec + ack/nack + dead-letter
• 跨節點即時通知在線 client、訂閱者離線可放棄 → broker 候選是 Redis Pub/Sub / NATS、量級訊號 sub-ms + 即時廣播、不保留

反推的目的是把「broker 比較」轉成「需求對齊」、避免從 vendor 規格表開始挑工具。下面四個維度是反推時要對齊的量級訊號。

吞吐量訊號

吞吐評估的核心問題是「broker 在我的 topology 下能撐多少」、不是「broker 規格上限」。同一個 broker 在不同 partition / queue / consumer / 訊息大小下、實際吞吐可以差一個量級。

實務量級（典型值、視配置與部署）：

對齊的問題是尖峰打進來後 broker 是否仍有 headroom（見 0.5 流量與資料量評估）。穩定流量 × 尖峰倍率 × fan-out 倍率才是真正要對齊的數字。

延遲訊號

延遲評估的核心問題是「業務能容忍 P99 多少」、跟 broker 級延遲特性對齊。請求-應答、fire-and-forget、事件流的可容忍延遲是不同量級。

實務量級：

• sub-ms 到個位數 ms：MQTT broker、NATS、Redis Pub/Sub — 即時通知 / 控制信號 / IoT 上報
• 個位數 ms：RabbitMQ classic queue、Redis Streams — 任務隊列 / 中等延遲事件
• 十 ms 到百 ms：Kafka（低 batch）、managed pub/sub — 事件流 / 分析 pipeline
• 百 ms 以上：Kafka 高 batch、SQS standard — 批次處理 / 容忍延遲的補送

陷阱是把「broker 內部延遲」當成「端到端延遲」。實際端到端通常被 consumer 處理時間 + 下游 I/O 主導、不是 broker 傳遞時間。

保留窗口訊號

保留窗口的核心問題是「事件需要被未來多久內的 consumer 讀到」。任務隊列吃掉就丟、事件流要可 replay、分析 pipeline 要留週級到月級。

實務量級：

• 不保留 / 短期：Redis Pub/Sub、MQTT QoS 0 — 只給「現在」訂閱者
• queue 級（持久但 ack 後刪）：RabbitMQ classic queue、SQS（最長 14 天）
• 中期（小時到天、受 RAM）：Redis Streams
• 天到月級（log-based、retention policy）：Kafka、Pulsar、NATS JetStream
• 永久 / tiered：Kafka tiered storage、Pulsar tiered storage

保留窗口直接影響成本：log-based broker 的儲存成本隨保留期線性增加、queue-based broker 的成本主要由「待處理深度」決定。

操作複雜度訊號

複雜度評估的核心問題是「團隊願意承擔哪些日常運維」、不是「broker 安裝多難」。安裝跟運維是不同量級工作。

實務量級：

• 低（managed）：SQS、Google Pub/Sub — quota / IAM / DLQ drain 是主要工作
• 低到中（self-host 但運維輕）：Redis Streams、NATS — 跟 Redis / NATS 本體運維捆綁
• 中（broker 級運維）：RabbitMQ — Erlang / clustering / mirrored vs quorum / network partition 處理
• 高（平台級運維）：Kafka self-host — partition rebalance / consumer lag / KRaft / topic governance / 跨 cluster 路由

複雜度的真正成本不在初期 setup、在「事故時誰能讀懂訊號」。挑 broker 時要問「下次 lag 暴增、團隊能在多久內找到原因」、這比 broker 規格表更接近真實業務考慮。

反推的常見陷阱

把「broker 規格上限」當需求對齊基準、會導致過度選型。Kafka 規格上百萬 msg/sec 不代表你需要 — 多數任務隊列場景在 RabbitMQ 萬級吞吐就足夠、Kafka 的 partition / consumer group / retention 治理成本反而是負擔。

把「現在吞吐」當未來基準、會導致欠選型。新 broker 通常要支撐 2-3 年成長、評估時要乘上預期成長倍率再對齊量級訊號。

把「規格表」當「實測值」、會在實際 topology 出問題。Broker 規格數字通常在最佳化測試環境得到、實際 production 受訊息大小 / consumer 速度 / 網路延遲 / replication factor 影響、實測常見差距 30%-60%。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入訊息傳遞實作章節：

1. 每種事件的投遞語意是否明確（可遺失、可重試、可重播）
2. 事件失敗後的路徑是否明確（retry、DLQ、replay）
3. consumer 的去重責任是否明確（idempotency 範圍與語意鍵）
4. 壓力保護條件是否明確（lag、queue depth、降級觸發）

下一步建議路由：

• 03-message-queue
• 08-incident-response

小結

非同步選型要先看工作需要什麼保證。本地工作用 local worker，可重試工作用 durable queue，可重播事件序列用 stream，即時 fan-out 用 pub/sub，資料寫入與事件發布一致性用 outbox。分類清楚後，RabbitMQ、Kafka、NATS、Redis Streams 等工具比較才有意義。

大量真實案例與轉換原因

案例分組判讀

語言與型別系統轉換

語言轉換常見於「延遲抖動不可接受」或「重構風險不可接受」兩類壓力。前者多是 runtime/記憶體模型問題，後者多是大型程式碼庫可維護性問題。

• 代表案例：Slack PHP -> Hack、Discord Go -> Rust、Dropbox Python 2 -> Python 3、Cloudflare C/NGINX -> Rust
• 主要動機：降低 tail latency、提升記憶體安全、對抗 runtime EOL、引入更強型別訊號

資料層與儲存架構轉換

資料層轉換通常源自單體資料庫在容量、隔離與可恢復性上出現結構性瓶頸，追新技術本身很少是真正驅動力。

• 代表案例：GitLab Main/CI split、Notion Postgres sharding、Shopify Vitess、Meta MyRocks
• 主要動機：解耦不同負載、降低熱點、取得水平擴充、降低儲存成本

平台與部署工具轉換

平台轉換通常發生在部署頻率提升後，原本的人工作業或弱自動化無法承擔發布風險。

• 代表案例：Figma 遷移 Kubernetes、Dropbox RPC 標準化到 gRPC
• 主要動機：統一部署控制面、縮短發布/回滾時間、提升跨語言協作效率

架構邊界重整

架構重整通常是「故障會跨邊界放大」或「團隊邊界與系統邊界失配」時的修正動作。

• 代表案例：Slack cellular architecture、Uber domain-oriented microservice governance
• 主要動機：縮小 blast radius、讓服務責任與組織責任對齊、降低跨團隊耦合

三倍擴充案例池（42）

這份案例池的核心責任是提供「可直接回寫實作」的案例母體，而不是只做公司清單。下面分成兩層：外部官方遷移案例（偏選型與轉換動機）與站內已整理案例（偏實作、驗證、事故教訓）。

A. 外部官方遷移案例（20）

B. 站內可回寫實作案例池（22）

這兩層合計 42 個案例。使用方式是先在 A 層找轉換動機，再到 B 層找可操作證據與失敗模式，最後回寫到 01/04/06/08 的正文。

跨分類覆蓋與缺口

這一段的核心責任是避免案例池被資料庫議題主導。選型與轉換在實務上會同時涉及快取、訊息傳遞、觀測、部署、安全與事故治理，因此案例覆蓋要跨分類配置。

覆蓋門檻與缺口追蹤

這份追蹤表的核心責任是把「案例夠不夠」變成可量化判斷，而不是主觀感覺。

下一輪優先順序

門檻已達標，下一輪優先順序改為：

1. 每分類補「失敗反例」與「轉換失敗回退案例」
2. 每分類補「同議題不同規模企業」對照
3. 把案例回寫到章節正文中的判讀訊號與 tripwire 欄位

回退失敗專題索引

這個索引的核心責任是讓讀者在「已經出錯」時，能快速找到對應回退失敗模式，而不是從頭重讀選型章節。

回退判讀寫法

回退判讀的核心責任是把失敗條件寫回該分類自己的業務語境。快取看的是回源壓力與資料新鮮度；queue 看的是語義、lag 與重播；observability 看的是訊號語意漂移；deployment 看的是切流、draining 與連線生命週期；security 看的是身份、憑證作用域與控制面擴散。

這些判讀不能抽成同一份模板。每次寫案例時，先回答該分類自己的問題：哪個業務路徑受影響、哪個訊號最早失真、哪個回退動作會降低傷害、哪份證據能證明回退有效。

下一輪補查清單（非 DB 優先）

下一輪補查會優先補目前中低密度分類，目標是讓每一類至少有 8 到 12 個可回寫案例。

1. Cache：快取策略遷移與失效治理（multi-layer、eviction、warmup）
2. Queue：broker/語義轉換與 replay 風險控制
3. Observability：監控平台遷移與資料品質治理
4. Deployment：部署平台轉換與灰度/回滾策略
5. Security：控制面信任邊界與憑證機制轉換

第二批外部案例補充（非 DB 類）

這一批的核心責任是把中低密度分類補到可用水位，讓 02/03/04/05/07 都有可引用的真實轉換案例，而不是只有資料庫案例可用。

第二批補查來源

• Meta：Cache consistency / mcrouter / CacheLib / Kangaroo / FOQS / MyRocks migration
• LinkedIn Engineering：Kafka at scale / TopicGC
• AWS：CloudHealth Kafka -> MSK、X-Ray -> OTel migration、ADOT/EKS 實務、EKS 遷移案例
• Google Cloud：OTLP in Cloud Trace、Orbitera -> GKE
• Shopify Engineering：cache serialization migration、write-through cache
• Cloudflare Post-mortem：2023/2026 control-plane 與路由事件

判讀訊號

轉換決策資料要求

轉換前要先回答的三個問題

1. 現有問題是「局部優化可解」還是「結構性不匹配」？
2. 轉換後的收益是性能、可靠性、開發效率哪一項，如何量化？
3. 遷移期間如何維持雙軌可運行與回退能力？

如果三個問題答不清楚，通常代表先做局部治理比全面轉換更穩定。

常見誤區

把「技術新舊」當成轉換理由，容易忽略遷移期成本。可靠做法是先界定症狀與邊界，再決定要換語言、換工具，或只換架構切分方式。

下一步路由

若問題在執行時特性（延遲抖動、記憶體模型），先回 0.2 與 0.5。若是資料庫轉換已進入執行階段，直接進 1.6 資料庫轉換實作；需要把 production migration 寫成 evidence、gate 與 decision log，接 1.7 Schema Migration Rollout 證據；需要放行與回滾治理時，接 6.11 Migration Safety；若要看事故層教訓，接 GitHub 2018 Oct21 MySQL Topology Incident。

引用源

• Hacklang at Slack: A Better PHP：Slack 說明 PHP 到 Hack 的遷移動機與型別收益。
• How Big Technical Changes Happen at Slack：Slack 逐步遷移與組織推進方式。
• Why Discord is switching from Go to Rust：Discord 說明 Go→Rust 的延遲與 GC 觀察。
• Slack’s Migration to a Cellular Architecture：Slack 從單體拓撲轉到 cell 架構的原因。
• The Long-Awaited Python 3 Upgrade at Dropbox：Dropbox 的 Python 2 -> 3 遷移動機與推進方式。
• Rewriting the heart of our sync engine：Dropbox 在核心效能路徑重寫的轉換決策脈絡。
• Courier: Driving the first years of gRPC：Dropbox 內部 RPC 到 gRPC 的演進背景。
• Splitting database into Main and CI：GitLab 的資料庫職責拆分案例。
• Sharding Postgres at Notion：Notion 分片遷移與容量壓力背景。
• Horizontally scaling the Rails backend of Shop App with Vitess：Shopify 導入 Vitess 的原因與方式。
• How Shopify Is Adopting Sorbet：Shopify 在大型 Ruby 程式碼庫導入型別系統。
• Migrating Figma to Kubernetes：Figma 的平台遷移原因與收益。
• A Rust regex engine in NGINX：Cloudflare 在高效能路徑導入 Rust 的案例。
• Domain-Oriented Microservice Architecture：Uber 在規模化後重整服務邊界。
• MyRocks: A space- and write-optimized MySQL database：Meta 導入 MyRocks 的成本與效能動機。

本章目標

學完本章後，你將能夠：

1. 區分 log、metric、trace、dashboard 與 alert 的用途
2. 判斷部署平台與可靠性驗證流程解決的問題
3. 用事故症狀和操作需求判斷應先補哪種平台能力
4. 把操作平台選型轉成可檢查的工程判斷

【觀察】操作問題會表現成診斷或交付困難

操作平台需求通常來自事故、擴容、發版或維護壓力。當服務在本機可用，但到生產環境後很難診斷、告警、部署或驗證，問題就已經超出語言本身。

這張表是索引。每種能力都可以採用不同產品與平台，但第一步是判斷你缺的是哪一種操作能力。

【判讀】log aggregation 承擔事件脈絡

log aggregation 的核心責任是收集可搜尋的操作事件。當工程師需要知道某個 request、event、worker 或 client 發生了什麼，log 是最直接的診斷入口。

接近真實網路服務的例子包括：

• 查某筆訂單 webhook 為什麼被拒絕
• 查某個 queue message 重試了幾次
• 查某個 client 連線何時建立、何時斷線

這類平台的主要風險是欄位不穩定與敏感資料外洩。log schema 要像 API Contract 一樣維持欄位名稱，並在服務輸出前控制 token、payload 與個資。

【判讀】metrics 承擔趨勢與容量判斷

metrics 的核心責任是把服務狀態轉成可聚合的數值。當團隊需要看錯誤率、延遲、throughput、queue lag、goroutine count 或 cache hit rate，metrics 是主要工具。

接近真實網路服務的例子包括：

• API p95 latency 是否持續上升
• queue lag 是否超過 consumer 處理能力
• Redis hot key 是否造成 timeout 增加

這類平台的主要風險是 cardinality。label 設計要能聚合趨勢，同時避免把 user id、request id 這類高基數欄位放進 metric。

【判讀】tracing 承擔跨服務路徑

tracing 的核心責任是把一次 request 或事件處理串成跨服務路徑。當一個操作會經過 API Gateway、Request Routing、service、database、queue、worker 和外部 API，trace 可以拆解每一段延遲與錯誤位置。

接近真實網路服務的例子包括：

• checkout request 經過 cart、payment、inventory、shipping 多個服務
• webhook 進入後觸發 queue，再由 worker 呼叫外部 API
• BFF API 聚合多個下游服務造成延遲不穩

這類平台的主要風險是 context propagation。服務之間要傳遞 trace id、span context 與 correlation id，否則 trace 會在邊界斷掉。

【判讀】dashboard 與 alert 承擔操作決策

dashboard 的核心責任是讓團隊看見服務健康；alert 的核心責任是把需要動作的異常主動送到負責者面前。兩者應該連到同一套 SLI、SLO 與 runbook。

接近真實網路服務的例子包括：

• API error rate 超過 SLO 時通知 on-call
• queue lag 超過可接受時間時提示擴容 consumer
• WebSocket disconnect rate 在特定地區突然升高

這類平台的主要風險是噪音。alert 應對應可執行動作；dashboard 應服務排障與容量判斷，圖表呈現則要服務這些操作目標。

【判讀】deployment platform 承擔服務交付

deployment platform 的核心責任是讓服務穩定啟動、更新、接流量、擴容與停止。當問題集中在發版、健康檢查、資源限制、流量入口或服務發現，應先評估部署平台能力。

接近真實網路服務的例子包括：

• rolling update 時新版本還沒 ready 就接到流量
• pod 被停止時還有 worker 和長連線尚未清理
• 多個 service instance 需要透過 load balancer 與 service registry、service discovery 協作

這類平台的主要風險是程式與平台合約不一致。服務要提供 readiness、liveness、graceful shutdown 與 resource usage 訊號；平台要根據這些訊號調度流量。

【判讀】reliability pipeline 承擔失敗前驗證

reliability pipeline 的核心責任是在事故前驗證系統承受能力。CI pipeline、load test、fuzz test、chaos test 都屬於可靠性驗證，但它們觀察的風險不同。

接近真實網路服務的例子包括：

• 發版前確認 API Contract 和 migration 能一起通過
• 高流量活動前用 load test 驗證容量
• 對 parser、protocol 或 input validation 做 fuzz campaign
• 在預備環境演練 broker、database、network failure

這類流程的主要風險是測試和真實系統脫節。可靠性驗證要對準實際 failure mode，並產出可行的修正或容量決策。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入操作平台實作章節：

1. 每種觀測訊號的責任是否明確（log、metric、trace、alert）
2. 告警是否對應可執行動作與 runbook
3. 部署平台與服務合約是否明確（readiness、shutdown、資源限制）
4. 可靠性驗證是否有固定入口（CI、load、chaos）

下一步建議路由：

• 04-observability
• 05-deployment-platform
• 06-reliability

小結

操作平台選型要先看團隊缺的是哪種運行能力。需要事件脈絡看 log，需要趨勢看 metrics，需要跨服務路徑看 tracing，需要共同操作入口看 dashboard，需要主動通知看 alert，需要穩定交付看 deployment platform，需要事故前驗證看 reliability pipeline。分類清楚後，產品與工具比較才會有明確目標。

本章目標

學完本章後，你將能夠：

1. 區分平均流量、尖峰流量、burst 與批次流量
2. 用讀寫比例、hot key 與資料成長辨識瓶頸形狀
3. 評估資料保留期限與查詢範圍對服務能力的影響
4. 避免用單一數字描述所有容量問題

【觀察】容量問題通常來自形狀差異

容量評估的第一個問題是「壓力如何出現」。同樣是一千個 request，每秒穩定進來、五秒內全部湧入、集中打同一個商品、或每次都查不同使用者，對系統的壓力完全不同。

這張表是評估索引。真正的容量討論要把數字放回產品情境，才能知道需要擴充哪種能力。

【判讀】平均流量決定基礎容量

平均流量的核心用途是估算日常成本與基本容量。穩定 API、背景 worker、資料同步與觀測資料，都需要知道平常每秒會產生多少 request、message、log、metric 或資料寫入。

接近真實網路服務的例子包括：

• 一個 B2B SaaS 白天每秒 50 個 API request，晚上降到每秒 5 個。
• 一個 webhook 平均每秒 20 筆事件，但每筆事件會觸發三個下游工作。
• 一個即時 dashboard 平均每秒收到 200 筆狀態更新。

這類評估的陷阱是只看平均值。平均值能估算基礎成本，但它無法說明尖峰、集中 key、批次匯入或下游失敗時的堆積風險。

【判讀】尖峰流量決定緩衝與降級策略

尖峰流量的核心用途是估算系統如何吸收短時間壓力。活動開賣、推播通知、直播開始、月底結帳、第三方批次同步，都可能讓流量在短時間內暴增。

接近真實網路服務的例子包括：

• 活動開始後前三分鐘的商品頁瀏覽量是平常的 30 倍。
• 推播送出後，大量 client 同時回到 App 查通知列表。
• 每天凌晨外部系統一次送入大量資料檔。

這類評估的陷阱是把尖峰當成一般擴容問題。尖峰可能需要 queue、backpressure、cache warmup、rate limit、預先產生 read model 或降級策略；單純加機器未必能保護資料庫、broker 或外部 API。

【判讀】讀寫比例決定資料路徑設計

讀寫比例的核心用途是判斷主要壓力在讀取、寫入還是交易一致性。讀多系統常需要 cache、read model 或搜尋索引；寫多系統則更關心 transaction、batching、queue、idempotency 與資料成長。

接近真實網路服務的例子包括：

• 商品頁是讀多寫少，資料可短暫快取。
• 訂單建立是寫入與交易一致性重點，狀態轉移要受保護。
• 行為分析事件是寫多讀少，讀取通常集中在離線報表或聚合結果。

這類評估的陷阱是只問資料量。十億筆冷資料和一萬筆每秒被反覆讀寫的熱資料，壓力來源完全不同。讀寫比例要和查詢模式、更新頻率與一致性需求一起看。

【判讀】hot key 會讓平均流量失真

hot key 的核心訊號是壓力集中在少數資料上。即使整體 QPS 看起來正常，單一商品、單一直播間、單一聊天室、單一熱門文章或單一 tenant 也可能打爆特定資料路徑。

接近真實網路服務的例子包括：

• 一個熱門商品承接大部分查詢與庫存扣減。
• 一個大型直播間同時有大量觀眾接收訊息。
• 一個企業 tenant 的使用量遠高於其他 tenant。

這類評估的陷阱是只做整體水平擴展。hot key 可能需要資料拆分、topic 分層、快取策略、讀寫分離、限流或產品層降級；具體做法要等需求形狀確認後再進入服務細節。

【判讀】資料成長與保留期限決定長期成本

資料成長評估的核心問題是「今天可用的設計，三個月後是否仍可用」。row、event、log、trace、object、index 都會成長；不同資料還有不同查詢頻率與保留需求。

接近真實網路服務的例子包括：

• 每天新增一百萬筆行為事件，但只查最近七天即時聚合。
• 每天新增十萬筆付款紀錄，法規要求保存多年。
• 每天產生大量 debug log，但事故排查主要看最近兩週。

這類評估的陷阱是把所有資料都放進同一個保存策略。正式狀態、audit、分析事件、debug log、trace、使用者上傳檔案需要不同保留期限、查詢方式與封存策略。

【判讀】查詢範圍決定索引與讀取模型

查詢範圍的核心問題是「使用者或系統實際會怎麼找資料」。查最近十筆、查單一 ID、查某個 tenant、查全文、查任意時間範圍與查聚合報表，需要不同資料模型。

接近真實網路服務的例子包括：

• 後台訂單頁主要查單一訂單與最近訂單。
• 客服系統需要依 email、電話、交易 ID 找到使用者。
• 分析頁需要依時間、地區、產品線聚合趨勢。

這類評估的陷阱是把所有查詢都塞進正式資料庫的單一模型。當查詢體驗、聚合方式或資料保留策略不同時，可能需要 read model、search index、analytics pipeline 或 archive，但這些都應來自明確查詢需求。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入容量與成本實作章節：

1. 流量形狀是否明確（平均、尖峰、burst、批次）
2. 主要壓力來源是否明確（讀寫比例、hot key、查詢範圍）
3. 成長假設是否明確（資料新增速度、保留期限、查詢頻率）
4. 容量保護策略是否明確（backpressure、rate limit、降級）

下一步建議路由：

• 9.13 擴展軸與 Stateless 前提（流量壓力出來後、選擴展軸）
• 5.9 邊緣分發與靜態資源（讀峰值的第一層緩衝）
• 02-cache-redis
• 03-message-queue
• 06-reliability

小結

流量與資料量評估要描述壓力形狀。平均流量估算基礎容量，尖峰流量決定緩衝與降級，讀寫比例影響資料路徑，hot key 會讓平均值失真，資料成長與保留期限決定長期成本，查詢範圍決定索引與讀取模型。這些資訊補齊後，服務選型才會有可靠依據。

這一章的內容是所有 Backend 服務實體章節的共同段落要求。後續討論 PostgreSQL、Redis、RabbitMQ、Kafka、Prometheus、Kubernetes、WAF、IAM、Secret Management 或任何具體服務時，都要回到同一組問題：資安限制會增加什麼成本，流量與穩定性會造成什麼壓力，伺服器與雲端費用如何成長，團隊要承擔多少操作成本，選擇這個方案會放棄哪些替代路線。

本章目標

學完本章後，你將能夠：

1. 區分建置成本、使用成本、操作成本與失敗代價
2. 用產品後果評估資料遺失、重複、延遲與停機風險
3. 判斷何時先用簡單設計，何時需要提前補能力
4. 把成本討論轉成可比較的選型問題
5. 在每個服務實體章節保留固定的成本與機會成本討論

【觀察】後端選型同時改變成本與風險

選型取捨的第一個問題是「這個能力降低哪種風險，又增加哪種成本」。資料庫、快取、queue、觀測平台、部署平台與可靠性流程都能提升能力，但它們也會增加操作面積。

這張表是成本索引。討論選型時，應把「技術是否強大」轉成「它是否值得目前承擔」。

【判讀】資安限制會改變成本模型

資安成本的核心問題是「安全要求會讓原本的服務選型增加哪些責任」。同一個資料庫、cache、queue 或 object storage，在沒有敏感資料與有個資、金流、企業權限、稽核要求時，成本模型完全不同。

接近真實網路服務的例子包括：

• 匯出報表若包含個資，系統需要欄位遮罩、核准流程、下載期限、audit log 與存取權限。
• 內部 service-to-service 呼叫若傳遞付款資料，可能需要 mTLS、signed request、credential rotation 與 trace 關聯。
• 客服查詢後台若能看到敏感資料，權限分級、操作稽核與資料最小揭露會成為必要成本。

這類取捨的核心風險是低估安全需求對操作面的影響。資安限制會增加設計、測試、稽核、教育訓練與事故處理成本；它也會降低資料外洩、權限誤用與合規事故的風險。服務章節討論選型時，必須把這兩邊一起列出。

【判讀】建置成本要和需求成熟度一起看

建置成本的核心問題是「需求是否穩定到值得建立能力」。需求仍在探索時，過度完整的平台能力會讓修改變慢；需求已經穩定且失敗代價高時，缺少能力會讓事故與重工成本上升。

接近真實網路服務的例子包括：

• 新功能只有少量 beta 使用者，先用簡單資料模型與明確 interface 保留替換空間。
• 付款流程已是正式收入來源，狀態一致性、audit、告警與回歸測試需要提前補上。
• 內部報表先用每日批次匯出即可，等查詢需求穩定後再討論更完整分析平台。

這類取捨的陷阱是把「未來可能需要」當成現在必須導入。比較穩定的做法是先定義 interface、資料責任與測試合約，等需求成熟或風險升高，再引入具體服務能力。

【判讀】使用成本要看成長曲線

本章的成本取捨發生在自建世界內；更早一層的成本交叉 — 託管平台月費加抽成、對上自建的工程薪資加雲端帳單 — 屬於交付形態的判斷、見 0.21 交付形態選型。

使用成本的核心問題是「流量與資料量成長後，費用如何變化」。儲存、查詢、訊息傳遞、log、trace、egress、compute 都可能隨使用量成長。

接近真實網路服務的例子包括：

• debug log 在小流量時成本很低，流量變大後集中式 log 費用快速增加。
• trace 全量採樣對低流量服務很方便，高流量後需要採樣與欄位控制。
• 長期保存大量事件可以支援 audit，但保留期限會直接影響 storage 與查詢成本。

這類取捨的陷阱是只看當月帳單。成本評估要看資料保留期限、查詢頻率、尖峰流量、跨區傳輸與成長速度，並把成本上限轉成明確策略。

【判讀】操作成本要看團隊能否承擔

操作成本的核心問題是「導入後誰能維護」。一項服務能力上線後，需要監控、備份、升級、權限、容量規劃、事故處理與文件。團隊若缺少操作能力，技術本身再合適也會變成風險。

接近真實網路服務的例子包括：

• 團隊導入多種 broker 後，需要同步建立 consumer lag、dead-letter 與 replay runbook。
• 服務開始使用多個快取層後，需要同步建立 失效策略 與 資料不一致 的排查方式。
• 部署平台支援自動擴容後，application 需要提供 readiness 與 graceful shutdown 合約。

這類取捨的陷阱是只計算開發時間。操作成本常在上線後才出現，因此選型時要把 runbook、告警、權限、備份、回復與測試環境列入範圍。

【判讀】失敗代價決定保證等級

失敗代價的核心問題是「錯誤發生時產品後果是什麼」。資料遺失、重複投遞、短暫不一致、延遲、partial failure、cascading failure、降級與停機的代價不同，對應的保證等級也不同。

接近真實網路服務的例子包括：

• 付款事件重複可能造成重複出貨或重複通知，因此 consumer 需要 idempotency。
• 聊天 typing indicator 遺失通常可接受，正式訊息遺失則需要保存與補送。
• 商品價格短暫不一致可能造成客訴，庫存短暫不一致可能造成超賣。

這類取捨的陷阱是追求所有資料都最高保證。高保證通常帶來更高延遲、成本與操作複雜度；合理設計會依資料語意分級，而非把所有訊息都放進同一種可靠性模型。

【判讀】機會成本決定投入順序

機會成本的核心問題是「做這件事會延後什麼」。後端能力建設很容易變成長期平台工程；它可能值得，也可能讓產品驗證變慢。投入順序要跟風險、成長與團隊能力對齊。

接近真實網路服務的例子包括：

• 產品仍在找市場定位時，先用清楚邊界保留替換空間，比導入完整事件平台更實際。
• 服務已經有穩定收入且事故頻繁時，補 observability、Deployment Contract 與 reliability pipeline 會直接降低業務風險。
• 流量即將進入大型活動前，先做 load test、容量預估與降級策略，比重構所有資料層更有時效。

這類取捨的陷阱是把架構完整度當成目標。選型應回答目前最需要降低哪個風險，並設計能回頭修正的邊界。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入具體服務取捨與落地章節：

1. 成本維度是否完整（建置、使用、操作、資安、機會成本）
2. 失敗代價是否分級（遺失、重複、延遲、停機）
3. 團隊可承擔的操作責任是否明確（runbook、告警、備份、回復）
4. 何時重評選型的條件是否明確（流量、法規、事故頻率）

下一步建議路由：

• 01-database
• 03-message-queue
• 07-security-data-protection

小結

後端服務選型要同時看成本與風險。建置成本要看需求成熟度，使用成本要看成長曲線，操作成本要看團隊能否承擔，失敗代價決定保證等級，機會成本決定投入順序。這些取捨清楚後，後續討論具體服務才會有共同標準。

本章目標

學完本章後，你將能夠：

1. 從需求面定義錯誤分類與定位線索
2. 判斷哪些錯誤需要對外回應、對內記錄、對平台告警
3. 設計可降級、可重試、可切換的服務行為
4. 把錯誤定位與備援需求連到 observability、deployment 與 reliability 模組

【觀察】錯誤設計是服務合約的一部分

錯誤設計的核心問題是「失敗時系統要留下什麼線索，並給誰什麼動作」。API response、domain error、log、metric、trace、alert、retry、fallback 與 failover 都是錯誤合約的一部分。

這張表是設計索引。錯誤定位與備援切換應在服務設計時討論，而非等事故後才補欄位。

【判讀】錯誤分類要服務呼叫者與維護者

錯誤分類的核心責任是讓不同角色知道下一步。呼叫者需要知道是否能修正輸入、稍後重試或停止操作；維護者需要知道錯誤來自程式規則、資料狀態、外部依賴、容量瓶頸或平台問題。

接近真實網路服務的例子包括：

• 使用者建立訂單時庫存不足，對外 response 要表達「目前狀態不允許」，對內 log 要能定位商品與庫存版本。
• 付款 API timeout，對外 response 要避免承諾付款結果，對內訊號要標出 payment provider、timeout duration 與 retry policy。
• Webhook payload 格式錯誤，對外要回穩定錯誤碼，對內要記錄 schema version 與來源系統。

這類設計的陷阱是只留下自由文字錯誤。自由文字適合人快速閱讀，但分類、查詢、告警與統計需要穩定欄位。錯誤分類要同時支援 API Contract、log schema、metric label 與 runbook。

下一步可讀：操作平台選型 與 可觀測性平台。

【判讀】定位線索要沿著 request 與事件流傳遞

定位線索的核心責任是讓工程師能把一個症狀追回完整路徑。當 request 跨過 API、資料庫、cache、queue、worker、外部服務與 WebSocket 推送時，線索需要跟著邊界傳遞。

接近真實網路服務的例子包括：

• checkout 變慢時，需要知道同一個 trace 經過 cart、payment、inventory 與 shipping 的哪一段。
• queue message 重試時，需要知道原始 request、event id、consumer、attempt count 與最後錯誤。
• 即時通知漏送時，需要知道 topic、client id、connection id、server instance 與 publish path。

這類設計的陷阱是每個元件各自產生無關 ID。request id、trace id、event id、subject id 與 dependency name 要有清楚用途，並在跨服務、跨 queue、跨 worker 時保留關聯。

下一步可讀：可觀測性平台。

【判讀】對外錯誤要穩定，對內錯誤要可診斷

對外錯誤的核心責任是讓呼叫者知道可採取的動作；對內錯誤的核心責任是讓工程師定位原因。兩者可以關聯，但承擔不同責任。

接近真實網路服務的例子包括：

• 對外回 payment_pending，讓 client 顯示等待確認；對內保留 provider timeout、request payload hash、attempt count。
• 對外回 rate_limited，讓 client 根據 retry hint 延後；對內記錄 tenant、limit rule、current usage。
• 對外回 resource_conflict，讓使用者刷新狀態；對內記錄 expected version 與 actual version。

這類設計的陷阱是把內部錯誤直接暴露給 client，或把對外訊息當成唯一診斷資料。對外錯誤要穩定、安全、可被產品處理；對內錯誤要保留足夠脈絡、可查詢、可關聯。

下一步可讀：操作平台選型。

【判讀】降級策略要依資料語意分級

降級策略的核心問題是「主要能力失效時，哪些功能仍可提供」。降級可以是回舊資料、只讀模式、排隊稍後處理、停用非核心功能、限制流量或切換較慢但可靠的路徑。

接近真實網路服務的例子包括：

• 推薦服務失效時，首頁可以回熱門商品或預先產生的榜單。
• Email provider 暫時失敗時，通知工作可以進 queue 稍後重試。
• 搜尋服務延遲升高時，後台可以先提供精確 ID 查詢，暫停全文搜尋。

這類設計的陷阱是所有功能共用同一種失敗行為。付款、訊息、搜尋、推薦、通知與報表的失敗代價不同；降級策略要依資料是否可丟、是否可延遲、是否可重建、是否涉及金流或稽核分級。

下一步可讀：成本、風險與選型取捨。

【判讀】備援切換要先定義切換條件

備援切換的核心責任是讓系統在依賴、節點或區域失效時轉到可用路徑。切換可以發生在 client、load balancer、service registry、service discovery、Integration Adapter、queue consumer 或資料層；每一層都需要明確條件。

接近真實網路服務的例子包括：

• 外部付款 provider 連續 timeout 後，系統暫停建立新付款並保留待確認狀態。
• 某個 service instance readiness 失敗後，load balancer 停止送新流量並進入 draining。
• 主要搜尋 cluster 延遲過高時，後台切到只讀快照或簡化查詢。

這類設計的陷阱是把 failover 想成自動且無代價。切換可能造成重複請求、順序改變、資料短暫不一致、成本上升或排障複雜度增加。切換條件、回切條件、資料一致性與告警都要一起設計。

下一步可讀：部署平台與網路入口 與 可靠性驗證流程。

【判讀】備援設計需要驗證流程

備援設計的核心完成標準是能被演練。文件中宣稱可以重試、降級、切換或回復，只代表設計意圖；可靠性驗證要證明這些路徑在接近真實條件下能運作。

接近真實網路服務的例子包括：

• 在預備環境讓 payment Provider Adapter 回 timeout，驗證訂單狀態是否停在待確認。
• 在 load test 中提高 queue lag，驗證 dashboard、alert 與 consumer 擴容決策。
• 在 chaos test 中讓 broker 暫時中斷，驗證 outbox、retry 與 idempotency。

這類設計的陷阱是只測成功路徑。錯誤分類、定位線索、降級策略與 failover 都應有對應測試、演練或 Release Gate，否則事故發生時才會知道設計缺口。

下一步可讀：可靠性驗證流程。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入觀測與事故治理實作章節：

1. 錯誤分類是否可被查詢與統計（對外碼、對內欄位）
2. 定位線索是否可跨邊界串接（request、trace、event）
3. 降級與切換條件是否明確（觸發條件、回切條件）
4. 演練與驗證入口是否明確（load、chaos、事故演練）

下一步建議路由：

• 04-observability
• 06-reliability
• 08-incident-response

小結

可觀測性與備援設計要從服務需求開始。錯誤分類讓呼叫者與維護者知道下一步，定位線索讓症狀能追回路徑，對外與對內錯誤承擔不同責任，降級策略依資料語意分級，備援切換需要明確條件，可靠性驗證則確認這些設計能在失敗時運作。

本章目標

學完本章後，你將能夠：

1. 用資料分級與角色分級描述安全需求
2. 判斷服務入口、內部通訊與資料匯出需要哪些保護
3. 區分權限控制、資料遮罩、傳輸保護、伺服器防護與稽核需求
4. 把資安需求連到後續安全與資料保護模組

【觀察】資安需求來自資料、角色與路徑

資安設計的第一個問題是「誰在什麼路徑上接觸什麼資料」。同一個系統可能同時有使用者、客服、營運、工程師、背景 worker、外部合作方與管理員；每個角色需要的資料、操作與稽核等級都不同。

這張表是需求索引。資安討論要先定義資料與操作的保護等級，再決定具體平台、服務或產品。

【判讀】權限分級要從角色與資料責任開始

權限分級的核心責任是控制角色能執行哪些操作。常見模型包括依角色授權、依屬性授權、依 tenant 隔離與依資源 owner 判斷；選型前要先定義資料責任與操作風險。

接近真實網路服務的例子包括：

• 客服可以查看訂單狀態與配送資訊，但付款敏感欄位只顯示遮罩版本。
• 營運可以調整活動商品，但價格變更需要主管審核。
• 企業 SaaS 中，workspace admin 可以管理成員，普通 member 只能操作自己有權限的 project。

這類需求的陷阱是只用「是否登入」表示授權。登入代表身份已被確認；授權要回答這個身份能否操作特定資源、特定欄位與特定動作。權限規則也要能被測試、稽核與解釋。

下一步可讀：7.2 身分與授權邊界。

【判讀】伺服器防護要先找暴露入口

伺服器防護的核心責任是降低服務入口的攻擊面。Public API、Admin Endpoint、webhook、file upload、public asset、Diagnostic Endpoint 與 Internal Endpoint 都有不同暴露程度。

接近真實網路服務的例子包括：

• webhook 需要驗證來源簽章、限制重放時間窗，並記錄來源系統。
• Admin Endpoint 需要更高權限、來源限制與操作稽核。
• file upload 需要限制大小、型別、掃描結果與後續存取權限。

這類需求的陷阱是把所有 HTTP 入口視為同一種入口。公開 API、內部 API、診斷 API、管理 API 與第三方 callback 的風險不同；防護策略要依入口用途分級。

下一步可讀：7.3 入口治理與伺服器防護 與 部署平台與網路入口。

【判讀】資料遮罩要依使用情境分級

資料遮罩的核心責任是讓使用者完成工作，同時降低敏感資料暴露。遮罩可能發生在客服畫面、匯出報表、log、debug payload、analytics dataset、測試資料與外部分享檔案。

接近真實網路服務的例子包括：

• 客服查會員資料時，只顯示電話末三碼與 email 部分字元。
• 匯出訂單報表時，付款識別碼保留交易對帳所需欄位，個資欄位轉為遮罩值。
• 開發環境使用脫敏資料集，保留資料形狀與關聯，但移除真實身份資訊。

這類需求的陷阱是把遮罩視為顯示層問題。資料可能流入匯出、log、queue、搜尋索引、分析資料集與備份；遮罩策略要定義在資料流路徑上，而非只套在單一頁面。

下一步可讀：7.4 資料保護與遮罩治理 與 可觀測性平台。

【判讀】傳輸保護要覆蓋跨邊界流動

傳輸保護的核心責任是保護資料跨越邊界時的機密性、完整性與來源可信度。邊界可能是 client 到 API、service 到 service、worker 到 broker、service 到 database、系統到第三方。

接近真實網路服務的例子包括：

• client 到 API 使用 TLS，避免帳號資料在網路中被竊聽。
• service 到 service 使用 mTLS 或 signed request，確認呼叫來源與訊息完整性。
• webhook callback 驗證簽章與 timestamp，降低偽造與重放風險。

這類需求的陷阱是只保護公開入口。內部網路、queue message、object storage link、backup transfer 與第三方 callback 都是資料流動路徑；傳輸保護要依邊界與資料等級設定。

下一步可讀：7.5 傳輸信任與憑證生命週期 與 部署平台與網路入口。

【判讀】密鑰與秘密管理要設計生命週期

密鑰與秘密管理的核心責任是控制 token、API key、private key、database Credential、session secret 與加密 key 的產生、保存、使用、輪替與撤銷，並把網站憑證納入 Website Certificate Lifecycle。

接近真實網路服務的例子包括：

• 第三方 API key 需要分環境保存，並能在外洩時快速撤銷。
• database credential 需要依服務分離，避免單一 credential 擁有過大權限。
• 簽章密鑰需要支援輪替期，讓新舊 key 在過渡期間都能驗證。
• 公網站點憑證需要有 ACME automation 或明確續期流程，並具備 certificate revocation 設計。

這類需求的陷阱是把秘密寫進設定檔、log、測試資料或部署指令。秘密管理要同時包含保存位置、存取權限、輪替流程、撤銷流程、憑證續期流程與稽核紀錄。

下一步可讀：7.6 秘密管理與機器憑證治理。

【判讀】稽核追蹤要服務事後責任判斷

稽核追蹤的核心責任是回答「誰在何時對哪個資源做了什麼，理由與結果是什麼」。高風險操作、管理員操作、資料匯出、權限變更、金流狀態修改都需要清楚 audit log。

接近真實網路服務的例子包括：

• 管理員修改使用者角色時，記錄操作者、目標使用者、舊角色、新角色與工單 ID。
• 客服匯出訂單資料時，記錄查詢條件、匯出欄位、資料量與核准者。
• 系統輪替 API key 時，記錄 key id、使用服務、輪替時間與生效狀態。

這類需求的陷阱是把 audit log 和 debug log 混在一起。debug log 服務排障，audit log 服務責任判斷；audit log 需要更穩定的 schema、保存策略、存取權限與完整性保護。

下一步可讀：7.7 稽核追蹤與責任邊界 與 可觀測性平台。

【檢查】進入實作前的概念邊界清單

當以下問題都能回答時，代表本章的概念層已完成，可以進入資安與資料保護實作章節：

1. 資料分級與角色責任是否明確（誰可讀、可改、可匯出）
2. 資料流路徑是否明確（client、service、queue、storage）
3. 秘密與憑證生命週期是否明確（保存、輪替、撤銷、續期）
4. 稽核與事故追蹤要求是否明確（audit 欄位、保存、查核流程）

下一步建議路由（按本章六議題對應）：

• 權限分級 → 7.2 身分與授權邊界
• 伺服器防護 → 7.3 入口治理與伺服器防護
• 資料遮罩 → 7.4 資料保護與遮罩治理
• 傳輸保護 → 7.5 傳輸信任與憑證生命週期
• 密鑰與秘密 → 7.6 秘密管理與機器憑證治理
• 稽核追蹤 → 7.7 稽核追蹤與責任邊界
• 事件處置 → 08-incident-response

小結

資安與資料保護要從資料、角色與路徑開始。權限分級控制誰能操作什麼，伺服器防護降低暴露入口風險，資料遮罩降低敏感資訊外流，傳輸保護保障跨邊界流動，密鑰管理控制秘密生命週期，稽核追蹤支援事後責任判斷。這些需求清楚後，後續才進入具體安全服務與平台能力。

本章目標

學完本章後，你將能夠：

1. 用事件生命週期描述非同步需求
2. 區分「可延遲」、「可重試」、「可重播」與「可去重」的責任邊界
3. 把訊息系統術語串成可檢查的決策流程
4. 判斷目前停在概念層，還是已經進入實作層

【判讀】事件生命週期先於產品選型

事件設計的核心問題是「事件在系統裡如何出生、傳遞、處理、失敗、重試與回放」。先回答生命週期，才有辦法判斷是否要用 broker、queue 或 stream。

一條最小生命週期通常包含：

1. 產生：producer 何時發布事件
   參考：Producer / Outbox Pattern
2. 傳遞：事件放在哪種通道
   參考：Queue / Topic / Broker
3. 消費：consumer 如何確認處理結果
   參考：Consumer / Ack/Nack
4. 失敗：重試與隔離如何發生
   參考：Retry Policy / Dead-Letter Queue
5. 回復：資料如何補送與重播
   參考：Replay Runbook / Offset

這條鏈路完整後，才進入 RabbitMQ、Kafka、Redis Streams 或雲端託管服務比較。

【判讀】投遞語意決定設計強度

投遞語意的核心問題是「失敗後，系統接受哪種結果」。at-most-once、at-least-once 與順序需求會直接決定重試、去重與補送成本。

接近真實網路服務的判斷方式包括：

• 通知類訊息可接受少量遺失：重點在低延遲與 fan-out。
• 金流或庫存狀態不可遺失：重點在持久化、重試與補償，並定義 strong reliability 路徑。
• 分析事件可接受短暫延遲：重點在可重播與批次處理。

對應卡片：

• Duplicate Delivery
• Idempotency
• Message Persistence
• Delivery Mode

【判讀】壅塞與延遲要用同一組語言處理

非同步壓力的核心問題是「輸入速度高於處理速度」。這會同時反映在 queue depth、consumer lag、timeout 與重試風暴。

對應卡片關係：

• 壓力來源：
  Backpressure / Queue Depth / Consumer Lag
• 保護策略：
  Rate Limit / Load Shedding / Circuit Breaker
• 失敗擴散：
  Retry Storm / Cascading Failure

這一層討論完成前，不需要先決定 broker 產品或 partition 數量。

【判讀】回復流程是可靠性設計的一部分

回復設計的核心問題是「錯誤發生後如何回到正確狀態」。DLQ、replay、Data Reconciliation 與 runbook 應該一起定義。

對應卡片：

• Dead-Letter Queue
• Replay Runbook
• Data Reconciliation
• Runbook

若這些概念只有名詞而沒有決策順序，系統上線後會把排障責任推給個人經驗。

【邊界】何時從概念章節進入實作章節

當以下問題都能回答時，代表概念層已完成，可以進入實作模組：

1. 哪些事件可遺失，哪些事件不可遺失
2. 哪些 consumer 需要去重，語意鍵是什麼
3. 何時重試、何時進 DLQ、何時啟動 replay
4. 哪些指標觸發擴容或降級

下一步建議路由：

• 進入訊息系統能力比較：03-message-queue
• 進入可觀測與事故流程：04-observability / 08-incident-response

本章目標

學完本章後，你將能夠：

1. 用「容量-觀測-資安」三軸描述服務治理需求
2. 把術語連成可追蹤的決策鏈，而非獨立名詞
3. 判斷何時先補觀測與操作能力，何時先補安全控制
4. 明確區分概念決策與平台實作邊界

【判讀】容量控制與恢復目標是一條線

容量治理的核心問題是「系統在壓力下如何守住核心能力」。timeout、deadline、backpressure、rate limit 與 fallback 應該連到同一個恢復目標。

對應卡片關係：

• 請求邊界：
  Timeout / Deadline
• 壓力控制：
  Backpressure / Rate Limit / Token Bucket
• 退讓策略：
  Fallback / Degradation / Failover
• 恢復目標：
  RTO / RPO

如果只定義 timeout，沒有 fallback 與回復目標，系統仍缺少操作上的可控性。

【判讀】可觀測訊號要服務操作決策

可觀測性的核心問題是「問題出現時，團隊能否在時間內採取正確動作」。log、metrics、trace、alert 與 runbook 必須一起設計。

對應卡片關係：

• 事件與脈絡：
  Log / Log Schema / Correlation ID
• 趨勢與目標：
  Metrics / SLI/SLO / Error Budget
• 路徑與定位：
  Trace / Trace Context
• 執行與回應：
  Alert / Alert Runbook / Runbook

當觀測鏈完整後，才適合比較具體平台組合。

【判讀】資安控制要對齊資料流與角色責任

資安治理的核心問題是「誰可以在什麼條件下接觸哪類資料」。身份、授權、傳輸保護、秘密管理與稽核需要同時成立。

對應卡片關係：

• 身份與存取：
  Authentication / Authorization / Least Privilege
• 傳輸與憑證：
  TLS/mTLS / Certificate Chain and Trust / Certificate Revocation
• 秘密與輪替：
  Secret Management / Certificate Rotation and Renewal
• 敏感資料與稽核：
  PII / Data Masking / Audit Log

若資安設計只停在單一工具，缺少資料流路徑與角色責任描述，章節仍停在術語層。

【判讀】事故治理把容量、觀測與資安接起來

事故治理的核心問題是「異常發生時，如何在可接受風險下恢復服務」。severity、on-call、timeline、RCA 與 game day 是將前面三軸落地的操作語言。

對應卡片：

• Incident Severity
• On-call
• Incident Timeline
• RCA
• Game Day

這些概念建立後，事故處理不會只依賴個人臨場反應。

【邊界】何時從概念章節進入實作章節

當以下問題都能回答時，代表概念層已完成，可以進入實作模組：

1. 核心服務的容量保護鏈是什麼（timeout 到 fallback）
2. 告警觸發後，runbook 的第一個與第二個動作是什麼
3. 高風險資料在系統內的流動路徑與存取角色是什麼
4. 事故升級與回報節點如何定義

下一步建議路由：

• 進入可觀測實作能力：04-observability
• 進入部署與可靠性能力：05-deployment-platform / 06-reliability
• 進入資安與資料保護能力：07-security-data-protection
• 進入事故治理能力：08-incident-response

【總表】服務類型與弱點判讀

【判讀】攻擊者視角總表在選型流程的位置

攻擊者視角總表放在產品需求與服務實體之間。流程上先做需求分類，再用這份總表檢查弱點與代價，最後才進入產品比較。這個順序能讓選型討論同步納入攻擊面與操作成本，避免把風險留到上線後才處理。

【判讀】弱點討論要對齊成本模型

弱點判讀的核心價值是提早看見操作成本。若只看開發速度，常見結果是上線後才補 runbook、權限分級、告警路由與備援切換。把弱點表納入選型初期，可以同時估算人力成本、容量成本與事故成本，讓服務能力與團隊負擔一起被評估。

【下一步】對應模組

• 資料層弱點路徑：模組一 database
• 訊息層弱點路徑：模組三 message queue
• 平台與入口弱點路徑：模組五 deployment platform
• 可觀測性弱點路徑：模組四 observability
• 資安與紅隊弱點路徑：模組七 security / red-team

這三類服務常被一起採購或一起導入，但它們回答不同問題。觀測平台回答「現在發生什麼」，可靠性工具回答「失敗前能否先驗證」，事故平台回答「事情發生後誰做什麼」。選型時先分清能力層，再比較 vendor、SaaS、OSS 或自建方案，能降低工具堆疊與流程空轉的風險。

選型錨點

選型錨點是先問服務要降低哪一種操作不確定性。當團隊只知道系統「好像怪怪的」，優先補訊號；當團隊知道風險但缺少安全驗證路徑，優先補可靠性驗證；當團隊知道事故已發生但協作混亂，優先補事故流程。

訊號層的責任是讓系統行為可被查詢與判讀。這一層的選型重點是資料模型、查詢能力、關聯能力、保留成本與告警品質；產品名稱排在後面，因為 log、metric、trace 與 error event 是否能互相串接，才是事故時真正影響判讀速度的條件。

驗證層的責任是讓風險在事故前被安全暴露。這一層的選型重點是測試是否接近真實 workload、故障注入是否有停止條件、SLO 是否能被量測、release gate 是否能阻止高風險變更；工具越強，越需要 blast radius 與權限邊界。

響應層的責任是讓事故進入可交接流程。這一層的選型重點是 paging、升級、角色分工、狀態更新、decision log、stakeholder mapping 與 post-incident action tracking；工具的價值來自流程一致性，通知訊息數量只是輔助訊號。

閉環層的責任是把事故與演練教訓回寫到系統設計。這一層可能由 incident platform、ticket system、runbook repository 或內部 workflow 承擔；判準是 action item 是否能被排序、驗證、關閉，並回到訊號治理、可靠性演練或事故流程。

判讀順序

操作服務選型的穩定順序是「症狀 → 缺口 → 能力 → 工具」。症狀描述使用者痛點或工程痛點，缺口描述目前缺少的判讀或流程，能力描述需要補的系統責任，工具才是最後的落地選項。

客訴比告警早代表系統的外部痛點先於內部訊號出現。這種情境應先補服務健康指標、使用者可感知訊號與 alert runbook，再討論要用哪個監控平台；否則平台上線後仍可能只收集到工程師方便看的資料。

trace 接不上 queue 代表跨邊界關聯失效。這種情境應先檢查 trace context、correlation id、message metadata 與 sampling 策略，再選擇 OpenTelemetry backend、APM SaaS 或 log search 方案。

發版後才發現容量曲線崩壞代表驗證層缺少 gate。這種情境應先建立 workload model、baseline、回歸門檻與 release gate，再選 load test 工具或 performance dashboard。

chaos 實驗影響超出預期代表驗證工具先於安全邊界。這種情境應先定義 steady state、blast radius、停止條件與授權範圍，再決定使用 chaos mesh、fault proxy 或商業 chaos 平台。

多人同時修事故但決策互相覆蓋代表響應層缺少 command model。這種情境應先定義 incident commander、scribe、owner、decision log 與 handoff，再導入 IR 平台或 chat workflow。

對外狀態更新慢於內部復原代表 stakeholder 節奏不足。這種情境應先定義影響評估、更新頻率、外部狀態頁與客戶溝通責任，再選 status page 或 customer comms 工具。

服務組合策略

服務組合策略的核心原則是先選最小閉環，再擴展平台覆蓋。完整閉環至少包含一個可判讀訊號、一個可驗證門檻、一個可接手流程與一個可回寫的 action tracking；缺任一層時，工具組合就會變成單點能力。

雲端原生整合適合雲端邊界清楚的團隊。它能快速取得 infrastructure 訊號、IAM 整合與預設 dashboard，但跨外部 SaaS、跨語言 trace 或高基數探索時，需要提前確認資料出口與查詢能力。

OSS 可組裝平台適合有平台團隊維護 ingestion、storage、query 與 dashboard 的組織。它能降低 vendor lock-in 並保留彈性，但容量規劃、升級、安全修補、保留策略與 on-call 都會變成內部成本。

All-in-one SaaS 適合需要快速建立可觀測、告警與事故協作的團隊。它能把 log、metric、trace、APM、paging 或 workflow 整合在單一產品，但成本模型、資料保留、客製化限制與資料治理要在導入前確認。

混合式最小閉環適合已經有多套工具的團隊。它的重點是定義哪個系統是 alert source、哪個系統是 incident source of truth、哪個系統負責 action item closure；整合邊界比新增工具更重要。

導入順序

導入順序的責任是降低一次導入多套工具的失敗風險。觀測、驗證與事故服務應依照事故風險與團隊成熟度逐層補齊，功能清單只適合放在能力判準之後。

1. 先補最小訊號：定義 SLI、error rate、latency、dependency failure、queue lag 與 customer-facing symptom。
2. 再補最小告警與 runbook：讓 alert 指向可執行動作，避免只把噪音送到 on-call。
3. 接著補驗證門檻：把 load、contract、migration、chaos 或 SLO 變成 release 前後的 gate。
4. 然後補事故協作：定義 paging、severity、角色、decision log、status update 與 post-incident review。
5. 最後補閉環治理：把偵測缺口、演練缺口與 action item 回寫到觀測、驗證與事故流程。

這個順序讓工具投資跟風險暴露同步。若團隊在沒有基本訊號時先導入 incident workflow，事故流程會缺少證據；若在沒有實驗安全邊界時先導入 chaos 工具，驗證本身會變成風險來源；若在沒有 action tracking 時只做 postmortem，復盤會停在文字紀錄。

交接路由

交接路由的責任是把服務選型判斷送到正確模組。選型章只決定「需要哪一類能力」，後續模組負責欄位、流程、工具與實作細節。

• 需要判斷訊號是否足以支援診斷時，進入 可觀測性平台。
• 需要判斷失敗是否能被安全驗證時，進入 可靠性驗證流程。
• 需要判斷事故是否能被接住與回寫時，進入 事故處理與復盤。
• 需要比較具體 vendor 時，先讀各模組的 vendors index，再回到本章確認工具是否補到正確能力層。

完成判準

本章完成的判準是能把工具需求翻成能力需求。當團隊能說清楚「我們缺的是訊號、驗證、響應還是閉環」，選型討論才適合進入 vendor 比較。

檢查時可以問四個問題：

1. 現在的痛點是看不見、驗不過、接不住，還是回寫斷掉？
2. 這個工具補的是哪一層能力，會產生哪些新操作成本？
3. 導入後誰負責維護資料品質、流程品質與 action closure？
4. 如果三個月後事故型態改變，哪個 tripwire 會提醒團隊重新評估？

概念定位

這一頁的責任是回答三件事：這家公司遇到什麼壓力、做了什麼選型決策、代價與回寫是什麼。提供企業層面的選型壓力對照，跟 0.19 雲端服務對照地圖 是 sibling：本頁是「實際企業怎麼決策」、0.19 是「能力 × vendor 名稱對照」。兩者並讀能避免「光看對照表選 vendor」或「光看案例抄架構」的兩種誤用。

使用方式是先從你的需求壓力切入，再對照對應案例，而不是先選喜歡的公司再倒推技術。這樣可以避免「抄架構」而忽略上下文差異。

使用方式

1. 先回到 0.0 後端需求分類地圖 定位你的問題類型。
2. 用本頁找 2 到 3 個不同規模企業的對照案例。
3. 把案例中的決策壓力回寫到 0.6 成本、風險與選型取捨。
4. 再進入對應模組（01-08）看實作與控制面細節。

案例地圖

案例按照「企業型態 × 規模階段」分組，目的是讓你先找到最接近自己情境的壓力來源，再看選型動作。

類型覆蓋檢查

案例蒐集的完成條件是覆蓋度，篇數本身沒有意義。每次補案例都用這四個維度檢查缺口。

第一批缺口回填清單

第一批回填先補三個目前缺口最大的產業類型，目標是讓案例圖譜從「網路平台公司視角」擴展到「高合規與高事件密度」場景。

這份清單的用途是定義下一輪蒐集方向。每補一個案例，至少要同步回寫一個 04 觀測章節、一個 06 驗證章節與一個 08 事故章節，避免案例只停留在選型敘事。

第一批案例清單（FinTech / Gaming / Healthcare）

第一批案例的責任是先補齊產業覆蓋，並建立可直接回寫到 04/06/08 的共同語言。

這批案例以「產業壓力類型」為主，不以單一公司唯一做法當標準答案。後續第二批再補製造業平台與跨國多區治理案例。

對應正文入口

第一批缺口已補對應正文，圖譜可直接連到可回寫文章：

營運一段時間後的語言、工具或架構轉換案例，見 0.C4 營運後技術轉換。

讀法提醒

同一家公司不代表同一答案。公司不同時期的選型結論可能相反，因為負載、組織、預算與產品階段已經改變。把案例當成「決策壓力樣本」，比當成「標準答案」更可靠。

當兩個案例做出不同選擇，先檢查四件事：流量形狀、資料生命週期、失敗代價、維運能力。這四件事通常比語言與框架更能解釋選型差異。

本篇與 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 等更複雜的分支。這些分支的模式相同 — 確認責任邊界、交接欄位與失敗判讀 — 讀者可以自行延伸。

為什麼需要這張對照地圖

兩種使用情境會需要這張表。第一是初次選型時，讀者已經選定主要雲廠商，要對照各能力分類找出 vendor 名稱。第二是跨雲遷移評估，讀者要對照源端跟目標端的能力 gap。沒有這張表，每次都要重新查文件、容易漏掉某個能力。

但這張表不能取代深入評估。每個 vendor 都有不在表格內的差異，例如配額、區域可用性、跨服務整合、計價模型。表格是路由起點，後續判讀要進到該 vendor 的 deep article。

能力 × 雲廠商對照表

這張表以全球 hyperscaler 三巨頭為主、不是市場全貌。Oracle Cloud (OCI) 在 enterprise / Java workload 跟金融受監管環境有顯著市佔；Alibaba Cloud 在亞太 / 跨境電商是主流；IBM Cloud 在金融 / 受監管環境仍存在；Hetzner / DigitalOcean / Vultr 在 cost-leader 區段提供完全不同的計價模型；Sovereign cloud（GDPR Schrems II 後在歐洲、JEDI / JWCC 在美國政府）是另一條獨立軸、跟資料主權合規綁定、比較對象不在這張表內。對照判讀邏輯（「對應 ≠ 等價」）可以同樣套用、但具體 vendor 名稱與差異維度要按目標廠商各自查證。

三家雲共同缺的能力分類

對照表覆蓋的能力都有 vendor 直接對應，但有兩類能力三家雲廠商都沒有提供等價的原生服務，要靠第三方工具補完。把這兩類獨立成段，避免在對照表中用「（無原生）」填空造成模板化。

壓測 / 流量重放：三家雲都沒有像 RDS 對 PostgreSQL 那樣的「managed 壓測服務」。團隊要從 k6、JMeter、Gatling、Locust、Vegeta、AWS Distributed Load Testing（這是 reference architecture 而非 managed service）這類第三方工具選擇。選型考量在於：是否支援該團隊熟悉的腳本語言（k6 用 JS / Gatling 用 Scala / Locust 用 Python）、能否分散執行、能否在 CI 整合、能否重放 production traffic（GoReplay、AWS VPC Traffic Mirroring）。各工具的選型細節見 9.3 壓測工具選型。

事故管理 / on-call 通知：三家雲都沒有原生的 incident management 平台。CloudWatch / Cloud Monitoring / Azure Monitor 只到 alert 層、不負責 escalation、on-call rotation、incident timeline 與 retrospective。這層責任目前由 PagerDuty、Opsgenie、Splunk On-Call（前 VictorOps）、Grafana OnCall 等第三方平台承擔。三家雲提供的 alert 可以 webhook 到這些平台，但 incident workflow 本身不在 cloud vendor scope 內。事故管理流程見 08 事故處理模組。

辨識這兩類「跨雲共缺」能力的價值在於：跨雲遷移時這兩層不會增加 vendor lock-in，可以保留現有第三方工具直接接到新雲；反之，cloud-native incident management 或 cloud-native 壓測這類規劃要在採購前確認是否真實存在，避免被命名類似的工具誤導。

「對應 ≠ 等價」的具體差異範例

對照表只給名稱對應，實際選型要看差異細節。下面四個常見的差異維度示範如何把名稱對應翻成選型判讀。

失效切換時間差異（RDS vs Cloud SQL vs Azure SQL）

同樣是 managed PostgreSQL，三家 vendor 文件給的 failover 時間參考值差距明顯。下列數字以各雲廠商公開文件為基準、實測長尾可能拖到更長：

• AWS RDS Multi-AZ：vendor 文件寫「typically 60–120 seconds」、P99 實測可達數分鐘
• AWS Aurora：vendor 文件寫「typically less than 30 seconds」、實測 30–90 秒常見
• GCP Cloud SQL HA：vendor 文件寫「1–2 minutes」
• Azure SQL Business Critical：vendor 文件寫「around 30 seconds」、實測 30–60 秒

選擇關鍵不是「哪個快」、而是「業務能容忍多少 downtime」。30 秒對 banking、ticketing 是不能接受的；對內部後台是無感的。失效切換時間直接影響 SLO 設定跟業務連續性 — 數字以 vendor 公開文件為參考、實際決策時要用該 vendor 自己的 SLA 條款跟 incident report 驗證。

一致性模型差異（DynamoDB vs Firestore vs Cosmos DB）

三家的 NoSQL 在一致性語意上分歧：

• DynamoDB：預設 eventual consistent read、可選 strongly consistent read（成本 2 倍）
• Firestore：strongly consistent read 是預設、跨 region 用 multi-region 配置
• Cosmos DB：五種一致性等級可選（strong / bounded staleness / session / consistent prefix / eventual）

如果應用程式假設「寫完馬上能讀到」（read-after-write），在 DynamoDB 預設模式下會撞牆。在 Cosmos DB 選 session consistency 可以保證單一 client 內 read-after-write、跨 client 仍是 eventual。這類差異要在選型階段對齊，不是事後改 code。

計價模型差異（Lambda vs Cloud Functions vs Azure Functions）

三家的 serverless 在計價單位有差異：

• Lambda：請求數 + 執行時間 (GB-秒)
• Cloud Functions：請求數 + 執行時間 + 網路流量
• Azure Functions：執行次數 + 執行時間 + 記憶體（Consumption Plan）或固定費用（Premium / Dedicated Plan）

對於低流量服務、三家差異不大；對於高頻率短時間函式、計價差異可能放大數倍（具體倍數視 memory size / 執行時間 / 流量分布、用 vendor calculator 算）。選型時要用實際 workload 估算、不能看單位價格表面數字。

跨服務整合差異（消息佇列 vs 觸發器）

AWS SQS + Lambda 整合非常成熟、有 native trigger；GCP Pub/Sub + Cloud Functions 同樣 native；Azure Service Bus + Functions 也有 trigger，但細節（dead-letter 處理、retry 策略、batch size）跟前兩家有差異。

跨服務的整合成熟度通常會在事故時放大差異。同樣的事件處理流程，在 AWS 上 90% 用 native 路徑、在另一家可能需要 30% 自己寫 glue code。

跨雲遷移的判讀重點

把這張對照表反過來讀，就是跨雲遷移的 gap 分析起點。但實際遷移要看四類風險：

第五類風險常被低估：以 AWS S3 為例、egress 約 $0.09/GB、PB 級資料即 $90k 帶寬費；GCP / Azure 同等級。跨雲遷移最大單筆成本經常是 data gravity、需要先決策資料拓樸再算其他三類風險。

跨雲遷移不是把服務名稱換掉就完成。每一個對應都要做 deep audit，這是 01 大規模 DB 遷移實戰 等模組的責任。

混合雲與多雲的情境

常見的混合或多雲組合：

• 資料留 AWS、ML 跑 GCP：因為 BigQuery、Vertex AI 在資料分析優勢
• 主要 Azure、ML 跑 AWS：因為 SageMaker 跟 Bedrock 提供的選項
• DR 在另一家雲：主要在 AWS、DR 站在 Azure 避免單一雲廠商故障

混合 / 多雲要解的核心問題是跨雲流量成本（egress）跟身分聯邦（cross-cloud IAM）。這兩個成本通常被低估，要在規劃階段就做進 cost model。

對照表使用的判讀順序

讀這張表時，避免以下兩種誤用：

第一是「看完表格就決定 vendor」。表格只給名稱對應，沒給選型理由。先確認自己的能力需求（容量、一致性、failover 時間、計價型態），再用表格找候選 vendor，再進該 vendor 的 deep article 驗證細節。

第二是「把『對應』當作可互換」。已經提到的失效時間、一致性語意、計價模型差異會直接影響業務。在做技術選型時不能假設「換家雲就行」，要驗證每一條差異。

正確的使用順序：能力需求 → 對照表找候選 → vendor deep article 驗證 → cost / failure / consistency 驗算 → 決策。

判讀訊號

常見誤區

把 vendor 對照表當「採購清單」，看完直接照表選。選型必須回到需求，不是看哪家有對應名稱就選。

把雲廠商當「commodity 商品」，假設換家就好。三家的整合生態、配額限制、計價單位都有差異、遷移成本經常被嚴重低估（特別是 data gravity / IAM / 監控重建這三類隱性成本）。

把單一雲廠商當「永遠不會變」。雲廠商會調整定價、棄用服務、改 API。設計時要有抽象邊界，避免直接綁定 vendor SDK 到業務邏輯，方便未來換家或多雲。

定位邊界

本章預設「自建於雲端基礎設施」已成立；讀者若在對照表看到 Firestore 而想問「乾脆整個用 Firebase？」、那是 BaaS / 託管平台層的交付形態判斷、見 0.21 交付形態選型。

本章專注「能力分類到 vendor 名稱的翻譯與對應差異」。當問題進入具體 vendor 配置（例如 RDS 怎麼設 backup）、跨 vendor 遷移流程（例如從 MySQL 遷到 Aurora），分別交給各模組的 vendors/ 目錄跟 migration playbook。當問題進入需求分類（這個業務需要強一致還是最終一致？）回到 0.0 後端需求分類地圖。

案例回寫

雲端服務選型可用以下案例回寫：

• 0.14 企業選型案例圖譜 — 0.14 收錄不同產業、不同規模階段企業的雲端選型決策；對照本章「跨雲遷移的判讀重點」段：合規、計價、IAM 整合是三家雲決策的主要分歧軸。
• 9.C20 Zomato：TiDB 遷到 DynamoDB — Zomato 把 SQL 介面（TiDB）換成 KV 介面（DynamoDB）、用一致性語意差異換取 4 倍吞吐 + 50% 成本；對照本章「對應 ≠ 等價」段中的一致性模型差異子段。
• 9.C23 Netflix：Aurora consolidation — 案例是 AWS 內 DB 種類整併（多 RDB → Aurora），可對照本章「對應 ≠ 等價」段中的計價模型與整合成熟度差異。雖然不涉及跨雲，但在同一家雲廠商內整併服務、跟跨雲整併共用同一條決策邏輯：權衡 vendor lock-in 代價 vs 運維碎片化代價。
• 5.C1 Tradeshift：self-managed K8s → EKS — Tradeshift 從自管 K8s control plane 遷到 EKS managed control plane、運維責任邊界從「整套 cluster」收斂到「workload + worker node」。對照本章「容器執行平台」對照行：managed 程度是同一能力分類下的主要分歧軸。

這些案例回答的是不同問題、不是同一個問題的不同切面。對照表本身只回答「叫什麼名字」；Zomato / Tradeshift 補「換掉名字後實際差多少」（介面 / 計價 / 一致性差異）；Netflix Aurora 補「同一雲內怎麼收斂」；0.14 補「真實企業在什麼壓力下選什麼」。讀者按手邊的問題進入對應案例、不需要也不適合串成同一條 narrative。

跨模組路由

1. 與 0.1 後端服務能力地圖 的交接：先確認能力分類，再用本章找 vendor 對應。
2. 與 0.6 成本、風險與選型取捨 的交接：cost model 是 vendor 選型的關鍵維度。
3. 與各模組的 vendors/ 目錄的交接：對照表只給名稱、deep article 給配置與運維。
4. 與 01 大規模 DB 遷移實戰 的交接：跨 vendor 遷移的具體流程。

下一步路由

對照表是查 vendor 名稱的第一層、進入細節要走 deep article：

• 實際企業選型案例 → 0.14 企業選型案例圖譜
• 資料庫 vendor 細節對比 → 01 模組 vendors/
• 部署平台 vendor 細節對比 → 05 模組 vendors/

本章不在規模成長路線上、是 sibling 工具型入口。要進規模成長路線、從 10.1 服務拆分 或 9.13 擴展軸 開始。

本章目標

讀完本章後、讀者能夠：

1. 用差異化位置與業務量判斷服務該落在交付形態光譜的哪一段
2. 看懂全託管平台、辦公生態自動化、BaaS、半託管 CMS 與自建各自的能力邊界與遷出代價
3. 在選擇託管形態的同時、保留日後遷往自建的可遷出路徑
4. 把「該升級自建了」的判斷從感覺轉成可觀察的 tripwire

【觀察】自建的合理性來自差異化位置

自建的合理性來自一個前提：這個產品的差異化在軟體本身。差異化在商品、內容、社群或服務品質的生意、軟體只是通路 — 通路用現成的、把工程資源留給差異化所在的位置、是成本上更誠實的選擇。

第一列的判讀方式值得展開：把產品的核心流程用一句話描述、再問「這句話是不是某個託管平台的官方首頁文案」。「賣手作飾品、信用卡結帳、出貨通知」就是 Shopify 的首頁；「活動報名、自動寄確認信、報名滿額關閉」就是表單工具加自動化的範圍。描述不出落在任何平台標準域的流程 — 例如「客戶上傳檔案後跑客製演算法、依結果動態計價」— 才是自建訊號。

「產品本身就是軟體」這一列要先過一個澄清：這個軟體是要賣的產品、還是經營業務的工具。「給健身教練用的課表系統」有兩種身分 — 開發者要賣給眾多教練的產品（市場上的垂直 SaaS 是競爭對手、交付形態走自建）、或教練管理自己學員的工具（同一批垂直 SaaS — 課表、預約、POS — 正是該優先評估的託管形態）。同一句需求描述、兩種身分的結論相反、先拆身分再進訊號表。

【判讀】交付形態光譜

光譜從左到右、控制力遞增、維運責任同步遞增。每一段先看它解什麼、再看邊界訊號與遷出代價。

全託管平台：Wix、Shopify、Squarespace、Google Sites

平台承擔整條技術棧：主機、憑證、防護、金流、版面。使用者操作的對象是「網站內容」、不是「程式碼」。電商走 Shopify、形象站與簡介站走 Wix / Google Sites、訂閱內容走 Substack 類 — 各平台的標準域內、上線時間以天計、且本系列 0.8 資安與資料保護需求 裡多數伺服器側的功課由平台承擔。

邊界訊號：客製需求開始對抗平台 — 結帳流程要插入平台不支援的步驟、資料要跟外部系統雙向同步、頁面效能撞到平台的模板天花板。在平台內 workaround 的程式碼（Shopify 的 liquid hack、Wix 的 Velo 腳本）累積越多、等於在用最差的開發環境自建。

遷出代價：資料匯出通常有官方管道（商品、訂單 CSV）、但 URL 結構、SEO 累積、會員密碼（雜湊不可攜、遷移等於全體重設密碼）、訂閱金流的扣款授權（綁在平台的金流帳戶上）都要重建。

辦公生態自動化：Google Apps Script + Sites / Forms / Sheets

這一段解的是「流程自動化」、不是「產品」。表單收件進試算表、定時整理寄報表、收到 email 觸發動作 — Apps Script 把 Google Workspace 的元件串成工作流、零主機、零部署、權限直接掛在 Google 帳號上。同段位的還有 no-code 資料庫工具（Airtable、Notion 當輕後台）— 串現成元件、零部署的角色相同。內部工具與小規模對外流程（報名、登記、排班）在這一段的成本接近零。

邊界訊號：第一個出現的通常是配額牆 — 某天報名表單停止收件、log 裡躺著超額錯誤、而且已經靜默丟了一個下午的提交。再來是併發：兩個人同時送出、Sheets 用最後寫入蓋掉前一筆。最後是工程紀律的渴望、腳本長到想要版本控制與測試時、它已經是一個沒有工程基礎設施的程式專案。

遷出代價：低 — 資料在 Sheets / Drive 裡天然可匯出、流程邏輯通常短到可以重寫。這一段的風險是「忘記遷」、不是「遷不動」：業務量上來後配額錯誤靜默發生、報名表單少收一批人才發現。

BaaS：Firebase、Supabase

BaaS 把後端拆成現成模組：認證、資料庫、檔案儲存、推播、serverless function。前端（app / SPA）自己寫、後端用平台的 SDK 直連 — 本系列 0.2 狀態與資料儲存選型 討論的多數問題、在這一段被平台的預設答案取代。行動 app MVP 與快速驗證期的產品、BaaS 把「後端工程師」這個角色延後了。

BaaS 的邊界牆通常分三面依序出現。第一面是報表 — 老闆要一張跨集合的月報、Firestore 查不出來、工程師開始把資料複製第二份、複製管線本身變成要維護的系統。第二面是帳單：讀寫計費隨流量線性成長、某個月的發票讓人重新打開計算機比對自建。第三面最安靜：client 直連資料庫的模型把授權邏輯全部塞進 security rules、規則檔長到沒人敢改時、0.8 的整個控制面已經壓在一個難以測試的規則語言（DSL）裡。

遷出的代價集中在資料層：資料本身可匯出、但資料模型沿平台特性設計（為遷就查詢限制、同一份資料複製存放多處的反正規化結構、加上平台專屬的即時同步語意）、遷到關聯式資料庫等於重做資料層。認證體系可攜性視平台而定（Firebase Auth 可匯出密碼雜湊、是少數友善案例）。

半託管 CMS：WordPress 與同類

WordPress 代表「半手動自定義」這一段：核心由開源專案提供、功能靠外掛拼裝、版型可以改到面目全非、主機可以託管也可以自架。內容為主、客製需求中等的站（媒體、部落格、預約、小型電商加 WooCommerce）長期住在這一段。控制力比全託管平台高一級：資料庫是自己的 MySQL、檔案是自己的目錄、想改什麼理論上都改得動。

邊界訊號：每次外掛更新前先全站備份、更新完手動點一輪主要頁面 — 這個儀式固定下來時、外掛堆疊已經超出任何人的全盤理解。效能問題跟著來：頁面變慢、但慢在哪一層查詢沒人說得清。資安面則是時間問題：WordPress 外掛漏洞是攻擊者的固定狩獵場、patch 責任在自己身上、沒人 patch 的站是 0.11 攻擊者視角 裡最便宜的目標。

遷出代價：真正遷不動的是外掛私有表裡的業務邏輯 — 會員等級、預約規則、客製欄位散在各外掛自己的資料表、遷移時要逐個考古；內容本身（文章、媒體）反而是最成熟的匯出路徑。

垂直 SaaS：行業專用的託管形態

垂直 SaaS（預約系統、課表排班、POS、訂位平台）是全託管平台的行業特化分支。平台已經把該行業的標準流程做成產品、使用者設定開通而非寫程式碼。業務流程落在平台標準域內時、效率跟全託管平台相同；差異在於當需求偏離行業標準域（例如預約系統要加客製的動態定價邏輯）、平台的 API 與 webhook 是延伸天花板 — 超出就是自建訊號。遷出代價集中在客戶資料與業務規則的可攜性：客戶名單、歷史交易紀錄的匯出格式、以及在平台 UI 裡長出來的行業特定規則（排班邏輯、會員等級、優惠券組合）能否帶走。

個人自架工具：常駐本機、無對外服務

這一段跟前面所有形態的本質差異在於：沒有對外使用者。遠端操控自己的主機、家庭自動化、個人備份同步這類工具、使用者就是所有者（單人或家人）。它在光譜上是自建的一個特例 — 自建成立、但本模組其餘章節的多數問題（租戶、使用者資料庫、對外服務）不適用。常駐在自有主機（launchd / systemd）或私有網路上、本模組裡真正展開的只剩三條：入口怎麼安全進來（部署平台）、誰能存取（資安）、密鑰怎麼保管（secret）;資料庫、快取、queue、多租戶隔離多半 N/A。

認證也離開 web-auth 光譜。沒有帳號系統、沒有 SSO、主體就是持有裝置的所有者：一層裝置原生生物辨識（Face ID / 指紋）認「人」、一層 app 與主機共享的密鑰認「連線」。入口形態常是 outbound tunnel（cloudflared / Tailscale）而非公網 IP — 本機主動外連、路由器零開 port。詳見 7.2 身分與授權邊界 的單人裝置認證段與 5.10 Outbound Tunnel 入口。

這個模型的邊界在使用者數。使用者從「自己」變成「自己 + 幾個朋友」時、第一個多出來的使用者就打破整個模型 — 共享密鑰無法分辨是誰、生物辨識綁在單一裝置、沒有帳號就無法個別撤銷。這時回到完整自建訪談、把認證升級成帳號系統。

遷出方向也跟其他形態相反 — 方向是「長成服務」、離開平台只是副產物。工具沒有累積對外使用者資料、遷移成本低;真正要重做的是認證與授權層（從單人共享密鑰換成多使用者帳號系統）、以及入口（從個人 tunnel 換成能承載多人的公開入口）。

自建：本模組其餘章節的世界

差異化在軟體本身、或所有託管形態的邊界都已撞到、就進入自建。自建的真正成本由本模組其餘章節展開：0.0 需求分類 開始、0.6 成本、風險與選型取捨 把人力與維運成本攤開。自建換到的是：資料模型自己定、流程任意客製、成本曲線在規模化後由自己控制、以及所有控制面（資安、觀測、備援）可以做到合規要求的深度。

【判讀】混合形態是常態、不是過渡期的妥協

光譜上的位置不必全站一致。常見的健康組合：行銷頁與內容放託管平台（Wix / WordPress）、核心產品自建、兩者用子網域分流；電商主站走 Shopify、客製的批發報價系統自建接 Shopify API；內部流程跑 Apps Script、對外產品自建。判讀單位是「每條業務流程」、不是「整間公司」— 把不是差異化的流程硬塞進自建 codebase、跟把差異化流程硬塞進託管平台、是同一個錯誤的兩個方向。拆分軸除了逐流程、還有逐層：headless 形態（託管平台當後端引擎、自建前端體驗層）是同一條流程內的層級混合、判讀方式相同 — 每一層各自問「差異化在這層嗎」。

光譜上還有兩個停靠點值得知道：靜態網站生成器（Hugo / Next.js export）搭配 hosting（Netlify / Vercel）介於全託管與半託管之間，適合文件站與行銷頁；Edge Functions（Cloudflare Workers / Vercel Edge）介於 BaaS 與自建之間，寫程式但不管基礎設施，適合輕量 API 與邊緣邏輯。兩者的邊界訊號與遷出代價跟相鄰形態類似，需求超出時回到各自相鄰段落的判讀。

【權衡】託管形態的成本與資安帳

託管形態把伺服器帳單換成平台帳單、把維運人力換成平台依賴。權衡時五個方向都要看：

1. 資安限制：平台扛掉 patch、憑證、DDoS 防護 — 這對沒有資安人力的團隊是淨收益。代價是資料主權與稽核深度受限：資料落在平台的儲存裡、audit log 細度由平台決定、有資料落地或合規要求（金融、醫療、政府標案）的業務、託管形態可能直接出局。
2. 流量與穩定性：平台的彈性通常優於小團隊自建（Shopify 扛 Black Friday 是它的本業）、但天花板不可協商 — API rate limit、配額、模板效能、撞到就是撞到。
3. 平台費用：月費 + 抽成（電商平台的交易抽成在量大後是實質稅率）。自建與託管的成本曲線會交叉、交叉點要算：平台月費 + 抽成 vs 自建的工程薪資 + 雲端帳單、在目前與三倍業務量下各是多少。
4. 人力與操作：託管形態讓非工程角色能直接維護（改文案、上商品、調流程）、這個能力在小團隊值很多錢；自建後每個改動都過工程隊列。
5. 機會成本：選託管、省下的工程時間投到差異化；選自建、買到的控制力要有明確用途。「以後可能要客製」是最常見的偽自建理由 — 客製需求出現時再遷、總成本通常低於提前自建養一套用不滿的基礎設施。

【檢查】可遷出保險：選託管的同時保留往右走的路

託管形態的真正風險是 vendor lock-in 的具體形：遷不出去。保險在進場時最便宜。選擇任何託管形態的同時、確認下列事項：

每項保險在遷出日如何兌現 — 保險與理賠流程的對應 — 見 10.3 託管形態遷出 的資產線盤點。

【檢查】升級自建的 tripwire

「日後可能需要自建」要轉成可觀察訊號、寫進選型記錄、而不是留在感覺裡：

tripwire 是重評承諾、不是遷移保證 — 觸發後每拖一季、資料量與整合深度都在墊高遷移成本。任一 tripwire 觸發時、回到本模組從 0.0 需求分類 走完整的自建選型；評估成立後的執行劇本 — 資產線盤點、並行期、回切窗口 — 見 10.3 託管形態遷出。

下一步路由

• 判斷落在自建：從 0.0 後端需求分類地圖 開始走本模組的選型順序。
• 判斷落在自建、但周邊能力仍想逐塊外包（認證、搜尋、金流、表單、後台）：見 0.22 能力級買 vs 建。
• 判斷落在個人自架工具（單人自用、無對外服務）：跳過資料庫 / 快取 / queue 章節、只看 7.2 單人裝置認證 與 5.10 Outbound Tunnel 入口;多人化時再回完整自建選型。
• 判斷落在託管形態：完成上方可遷出保險清單、把 tripwire 寫進選型記錄、定期回看。
• 成本曲線的算法：見 0.6 成本、風險與選型取捨。
• 託管形態下仍需要的資安底線（帳號安全、權限、資料匯出管控）：見 0.8 資安與資料保護需求。
• 從託管遷往自建的執行劇本：見 10.3 託管形態遷出；模組總覽見 模組十：系統演進與遷移。

本章目標

讀完本章後、讀者能夠：

1. 把「買 vs 建」的判斷單位從整個系統下降到單一能力
2. 辨識三種外包深度（managed 基礎設施、feature SaaS、BaaS bundle）與 no-code 到 dev-tool 的服務光譜
3. 用 commodity、合規、長尾成本與團隊規模判斷一塊能力該買還是該建
4. 算清外包的隱性帳：整合接縫、鎖定、遷出代價、以及權重如何隨情境浮動

【判讀】先確認該不該讀這章

本章預設讀者已經過了 0.21 的 whole-system gate、決定自建核心。在那之前有一種讀者該先被擋下來：非工程師、目的是解自己的生活痛點或做第一個 MVP 的人。對這種讀者、0.21 已經把答案給完了 — 用 BaaS（Supabase、Firebase）就是對的起點、本章的逐能力拆解反而是過度工程。免費額度對個人專案通常夠用、BaaS 連後端與資料庫的串接、效能調教、資源調配一起省掉、把這些當成「之後真的撞牆再說」的問題、是這個尺度最誠實的選擇。

常見的誤判是把選型問題問錯層。「我該選什麼資料庫」這個提問、對非工程師多半真正的答案在 0.21（這個尺度根本不必自己管資料庫）、不在本章。下表把提問者的身分對應到該回的章節：

第一列展開說明：判斷自己是不是這種讀者、看「撞牆之後誰來修」。個人專案撞到 Supabase 免費額度上限時、升級付費方案或匯出資料換平台都是幾小時的事、不需要先把架構拆乾淨。把工程資源花在「現在還沒發生的擴展問題」上、是把 0.6 成本、風險與選型取捨 講的機會成本花在錯的地方。確定自己是要自建核心、且周邊有多塊能力要逐一決定買或建、再往下讀。

【判讀】三種外包深度與 no-code 到 dev-tool 光譜

外包一塊能力有深度之分、不是非黑即白的二元動作（見 Capability Outsourcing Depth 卡片）。同樣是「不自己寫」、把維運交出去跟把整塊能力連業務邏輯一起交出去、控制權與遷出代價差一個量級。下面這三層講的是把能力交給雲端託管側時、交出多少 — 自架 OSS 或買 on-prem 授權、只租控制平面的自管形態是另一條平行軸（鎖定點在運維 know-how 與授權、不在 vendor API）、不收在這三層裡。下表把三種深度分開、每種附代表服務與遷出代價：

managed 基礎設施是最淺的外包：vendor 接手備份、修補、failover、擴容、跨區複製、但 schema、query、index、資料模型還是你的。遷出時資料是標準格式、架構是自己畫的、換一家 managed PostgreSQL 主要是搬資料與改連線字串。撞牆時你改得動的邊界很寬 — 慢查詢自己優化、index 自己加、只有底層硬體與維運動作在 vendor 手上。不過「邊界很寬」有前提：受限的 serverless 或內嵌型 managed（沒給 superuser、裝不了 extension 的那種）邊界其實更窄、選之前要確認需要的控制權它給不給。

feature SaaS 把整塊能力連同它的內部業務邏輯一起交出去、你消費的是一組 API 而不是一台機器。買 Auth0 不只是省下跑一台認證伺服器、是把「密碼雜湊策略、MFA、SSO、social login、session 管理」整套交給 vendor、你只接它的 SDK。代價是你改得動的邊界縮到 vendor 開放的擴展點為止 — 它沒給的客製、你做不到、繞過去就是在 vendor 之外再搭一層。遷出代價中到高、因為資料模型與業務規則都沿 vendor 的特性長出來。

選 feature SaaS 真正在賭的、是它的擴展點夠不夠你長出差異化。commodity 能力的多數需求跟同業一樣、買現成就解決；會區分產品的是少數、而那少數得疊在 vendor 之上自己長 — 但要先確認那塊差異化存不存在：有些 commodity（收個款、寄封信）差異化趨近零、整塊就是純買、這條擴展點判準根本不啟動。判準只在「確實有一塊差異化要疊上去」時才是選型核心。能不能疊、看 vendor 把控制權開到哪 — 開 API 讓你改它的排序、規則、把自己的資料接進它的邏輯、差異化長得出來；只開一面設定面板、核心邏輯動不了、一撞到差異化需求就得繞到 vendor 外另建一塊補。所以選的時候除了問「它做不做這塊能力」、更關鍵的是「它讓不讓我在上面長出獨有的那部分」 — 這一題決定它能陪產品走多遠。

跨能力 BaaS bundle 是一個 vendor 同時提供多塊能力、用整合當賣點。它的遷出代價最高、來自多塊能力被同一套整合綁在一起、不在任何單一能力 —— 例如同一組登入身分同時管資料庫、檔案與即時訂閱的權限、搬走其中一塊就要拆開這層共用整合（見下方 bundle 專段）。

這三種深度橫切一條 no-code 到 dev-tool 的光譜、而光譜的兩端服務不同的人。feature SaaS 這一層特別明顯：Auth0、Algolia 是 dev-tool、要寫 code 接 API、客製空間大、但需要工程整合能力；Ragic、SurveyCake、Airtable、Typeform 是 no-code、連 schema 都不必碰、填表就能用、客製天花板通常較低、但起步門檻也低到非工程師能獨立操作。選哪一端不只看「需要哪塊能力」、更看「誰來維護它」。一個沒有工程隊的小團隊、把會員資料放 Ragic、滿意度調查放 SurveyCake、是把維護權留在能自己改的人手上；同樣的能力換成 Auth0 + 自建問卷服務、每次調整都回到工程隊列、對這種團隊反而更貴。

【觀察】什麼訊號指向「買這塊能力」

一塊能力該優先評估外包、訊號集中在「自建不產生競爭優勢、卻要承擔沒有上限的長尾成本」。下表列可觀察訊號與它指向的判斷：

commodity 這一列是最常見的買訊號。認證、Email 投遞、金流處理、問卷蒐集、物件儲存 / 檔案 / CDN、後台操作介面（internal tooling）都落在這裡 — 每個產品要的功能幾乎一樣、自己寫一套不會讓產品更有競爭力。後台介面值得特別點出：很多團隊把「完整後台可操作」當成自建理由、但 admin panel 本身是 commodity、Supabase Studio、Retool、Appsmith 這類工具讓你連著資料庫就生出可操作的後台、把工程時間留給真正客製的業務流程。

自己架一台 SMTP 寄 email 看起來簡單、真正的成本藏在 deliverability — SPF、DKIM、DMARC、IP 信譽、退信處理、進垃圾桶的排查、是一條沒有終點的維護線、而 SendGrid 這類服務把這條線變成它的本業。這就是長尾成本最容易被低估的地方：金流的反詐欺、認證的 MFA 與 social login 矩陣同理 — 第一版很快、長期維護吃掉的人力沒有上限。

【觀察】什麼訊號指向「自建或搬離」

外包不是預設終點、有四種訊號會把一塊能力從「買」翻回「建」。這一段是對照、判斷時跟上一段的買訊號一起看、不是讓否定句主導決策：

會把一塊能力翻回自建的訊號裡、差異化核心是最硬的一條。一塊能力如果就是產品賣點 — 推薦引擎之於內容平台、媒合演算法之於媒合服務 — 把它外包等於把競爭力外包、再貴也該自建。但「差異化核心」是最容易拿來自我說服的標籤 — 下手自建前先用買訊號表的 commodity 判準反向驗一次：同業是不是也都這樣做、做得再好客戶會不會無感？會、它其實是偽核心、「再貴也建」不適用。其餘三列是「原本買得對、條件變了該重評」：客製撞牆、成本交叉、合規不滿足、都是把選型結論拿出來重算的 tripwire、而不是一次定生死。觸發後的搬離執行 — 並行期、回切窗口、資產盤點 — 見 10.3 託管形態遷出。

【判讀】四個真實例子

例子的責任是建判斷錨點。下面四個刻意走四種不同方向 — 黏合型、買到部分搬離、永遠買、建到改買 — 避免把「逐能力外包」講成單向的故事。

一個親子活動 app 的形狀最能展示「決策單位是能力」。需求包含親子活動預約、室內空間遊玩預約、親職文章分享、會員資料、滿意度調查、線上諮詢。拆開來看：會員資料與空間預約接 Ragic、滿意度調查接 SurveyCake、文章只是連結跳轉、真正需要自建的差異化只有「線上諮詢內容匯整成固定格式檔」這一塊。這個 app 的本質是整合層 — 把幾個 no-code SaaS 黏起來、自己寫的部分極小。資料庫選 Supabase 還是 Neon 在這裡幾乎是次要問題、真正的工程量在「會員資料同時存在 Ragic 跟 app、要不要同步、諮詢內容怎麼流到固定格式檔」這些接縫上。逐能力看、它的決策是「五塊買、一塊建」、不是「選一個資料庫」。

一個成長期的 SaaS 走的是相反路徑的前半段。它早期用 Supabase 全包上線 — Postgres、Auth、Storage、Realtime 一次到位、團隊不必碰後端。業務量上來後、資料層的 query 複雜度與成本超過 Supabase 託管 Postgres 的舒適區、團隊把資料層搬到自管 PostgreSQL、但認證留在 Supabase Auth。這是逐能力遷出的典型 — 只把撞牆的那一塊（資料層）搬走、沒撞牆的（認證）留在原地、整包搬離反而是錯誤思路。

一個自建電商展示「永遠買」的判斷。核心交易流程、商品、訂單、庫存全部自建、因為那是差異化所在。金流則永遠接 Stripe — PCI 合規、反詐欺、各國支付方式是 Stripe 的本業、自建金流要承擔的合規與長尾成本沒有任何回報、因為「能收錢」不構成競爭優勢。這個「永遠買」是對絕大多數團隊的預設、不是無條件鐵律 — 例外要先攔在前面：做受監管清算、金融牌照或資金存管業務的團隊、接 vendor 不會把這些合規責任接走、得回到自己業態的前提判斷、別照抄「金流永遠買」。要分清這裡「買」涵蓋的是哪一層：收單（把一筆卡片交易實際跑完、完成扣款）、卡片資料、PCI 合規、各國支付方式這層、對絕大多數團隊從第一天到規模化都是買、收單就是終點。會翻回自建的是更上層的支付編排（orchestration）。當一家公司同時接多個 PSP（payment service provider，實際完成扣款的金流商、如 Stripe、Adyen）、就需要一層編排決定每筆交易走哪家、哪家失敗換哪家重試、月底跟各家對帳。這層協調的複雜度跨多業務線後超過任何單一 vendor 能給、超大規模下才會把它拿回自己手上；但拿回的是收單之上的協調邏輯、底層的 PCI 與卡片處理仍然外包。對本章設定的讀者、金流買到收單這層就是答案、編排層的自建是規模到了才會出現的 tripwire —— 而多數產品永遠到不了那個規模、orchestration 對它們是不會觸發的分支、不是必經路徑；少數例外是高度監管或特殊清算需求的團隊、小規模就可能直接 direct acquiring（跳過 PSP 直接對接收單行）。

站內搜尋走的是反方向 —— 建到改買。一個內容站初期用自建 Elasticsearch、隨內容成長、維運這套搜尋（叢集調校、相關性排序、同義詞、中文斷詞）吃掉的人力越來越多、而搜尋品質始終追不上專做這件事的服務。團隊把搜尋換成 Algolia — 一塊原本自建的能力、因為長尾運維成本翻轉、改成外包。方向跟前三個都不同、但判準一致：這塊能力的維護成本有沒有回報。

【判讀】跨能力 bundle 的特殊判讀

跨能力 BaaS bundle 難放進以能力分章的結構、因為它一次交付多塊能力。Supabase 同時是 Postgres、Auth、Storage、Realtime 與 Edge Functions、橫跨本系列的 01 資料庫、02 快取、03 訊息佇列、05 部署 與 07 資安。以能力分章的教材、放不下「一個 vendor 給五塊能力」這種形狀、所以 Supabase 在資料庫章節只能當 managed PostgreSQL 比較表裡的一行 — 本章是它在選型層的上層錨點。

bundle 的價值與鎖定同源、都來自整合。同一套認證身分貫穿資料庫的 row-level security、Storage 的存取控制與 Realtime 的訂閱權限、是 bundle 最大的賣點 — 一次設定、多塊能力一致生效、省掉自己接縫的工作。但這份整合反過來就是遷出阻力：搬走任何一塊、都要把它跟其他幾塊的整合關係拆開重接。bundle 的高遷出代價不在資料量、在這些被同一套整合綁住的能力之間。

判讀 bundle 的單位仍然是逐能力。Supabase 不是一個必須整包接受或整包拒絕的決定 — 你可以只用它的 Postgres 當 managed 基礎設施、認證自建或接 Auth0；也可以反過來、資料庫自管、只用 Supabase Auth。問「我需要哪幾塊」「這幾塊的整合值不值得換取遷出代價」、比問「要不要用 Supabase」更準。

這也澄清一個常被混為一談的並列：Supabase 跟 Neon 不在同一個外包深度。Neon 是 managed 基礎設施、純 serverless PostgreSQL、給你一個會自動擴縮的資料庫、其餘能力自理；Supabase 是 BaaS bundle、資料庫只是它的一塊。只需要一個資料庫、兩者都行、Neon 更輕、遷出代價更低；需要認證、儲存、即時同步一起到位、才是 Supabase 的賣點。把它們當同級選項比較、會錯估各自真正交付的範圍。

【權衡】六方向成本與權重隨情境浮動

外包一塊能力的成本帳有六個方向、但這六個方向不是等權的 — 權重隨讀者與規模浮動、用同一張等權表套所有情境會把真正主導的軸攤平。先定權重、再看方向。

MVP 與個人專案主導的是三個方向：免費額度天花板、整合接縫工作量、長大後的鎖定。金流 / PCI 合規與流量穩定性對一個親子活動預約 MVP 近乎無關 — 沒有信用卡資料、沒有尖峰流量 — 但「合規」不能整類劃掉：這個 app 蒐集兒少個資、在多數司法管轄區（COPPA、GDPR-K、台灣個資法）反而是高敏感類別、同意機制與資料存放地點要照規矩走。把金流合規與流量這兩個方向跟其他四個並重討論、只會稀釋真正要看的「免費額度夠不夠、SaaS 黏起來累不累、以後搬不搬得動」。企業與規模化則相反、主導的是合規、流量穩定與計費的線性成長、免費額度天花板根本不在視野裡。

六個方向：

1. 資安與合規：外包認證把身分攻擊面交給 vendor、對沒有資安人力的團隊是淨收益；代價是 audit log 細度、資料存放地點（落在哪個國家 / 區域）與稽核深度受 vendor 限制、有合規要求的業務可能直接出局。
2. 流量與穩定性：SaaS 的 rate limit 與 SLA 變成你的天花板、不可協商；vendor 故障時你跟著故障 — 買一塊能力等於接受一個外部單點依賴。這個依賴的極端是 vendor 自己 sunset、倒閉或被併後關停 — 跟「你想走的鎖定」相反、是 vendor 先走、後果不可逆、選有長期生存力的 vendor 是這條的隱性成本。
3. 伺服器與雲端成本：計費形狀（per-MAU、per-request、per-seat、免費額度上限）決定成本曲線。個人專案看免費額度夠不夠、規模化看線性成長何時跟自建的固定成本加人力出現交叉點。
4. 人力與操作：外包省下維運、換來 vendor 管理 — SDK 升級、API 變更追蹤、定價政策變動的因應、都是新的操作成本、只是從機房移到供應商關係。
5. 機會成本：買對、省下的工程時間投到差異化；買錯、付出遷出代價加 vendor lock-in。「以後可能要客製」是最常見的偽自建理由、客製需求真的出現再遷、總成本通常低於提前自建。
6. 整合接縫成本：每多買一塊 feature SaaS、就多一道接縫 — 資料跨 SaaS 重複（會員同時在 Ragic 跟 app）、跨來源一致性、整合維護。買越多塊、系統的真正複雜度從「每塊能力內部」移到「能力之間的縫」。這是外包換來的隱性帳、跟「省下維運」是同一個決策的反面、評估買 vs 建時要跟省下的成本一起算。

下一步路由

• 還沒過 whole-system gate：先讀 0.21 交付形態選型、判斷整個系統該不該自建。
• 成本曲線交叉點的算法：見 0.6 成本、風險與選型取捨。
• 逐能力的 managed 選項：資料庫見 Managed PostgreSQL 比較、認證見 07 資安 vendor 清單、佇列見 AWS SQS。
• 外包能力撐不住要搬回自建：執行劇本見 10.3 託管形態遷出。
• BaaS 的概念背景：見 BaaS 知識卡片。

章節列表

本章目標

學完本章後，你將能夠：

1. 把後端需求拆成可討論的工程類型
2. 用產品情境辨識狀態、讀取、非同步、即時、診斷與交付需求
3. 找出需求討論中的常見陷阱
4. 把需求類型連到後續選型章節

【觀察】產品功能通常混合多種後端需求

需求分類的第一個判斷是「這個功能其實包含哪些後端責任」。例如一個電商結帳流程看起來是單一功能，但它可能同時需要保存訂單、查商品與庫存、呼叫付款、寄通知、更新報表、記錄操作訊號與支援發版回滾。

這張表是需求索引。每個類型後面都會對應到不同的能力地圖，但實際功能常會同時命中多列。

【判讀】狀態保存需求要先找正式狀態

狀態保存需求的核心訊號是「資料會被後續流程承認」。當使用者、營運人員、付款系統或稽核流程都需要相信某份資料，這份資料就需要明確的 source of truth。

接近真實網路服務的例子包括：

• 訂單建立後，付款、出貨、客服與退款都依賴同一筆訂單狀態。
• 會員升級方案後，API 權限、帳單與使用量限制都要讀到同一個 plan。
• 文章發布後，公開頁面、搜尋索引與後台審核都要知道目前版本。

這類需求的陷阱是把「看起來能存資料」的地方都當成正式狀態。快取、搜尋索引、log 與事件流可能保存資料副本，但它們承擔的責任不同。正式狀態要回答誰能寫入、哪些欄位要一致、失敗後如何恢復。

下一步可讀：狀態與資料儲存選型。

【判讀】讀取壓力需求要先找重複讀取路徑

讀取壓力需求的核心訊號是「同一類資料被大量重複讀取」。這種壓力通常先出現在熱門頁面、權限檢查、設定查詢、推薦摘要或即時狀態查詢。

接近真實網路服務的例子包括：

• 活動商品頁在短時間內被大量瀏覽，但商品描述變更頻率低。
• 每個 API request 都要讀取使用者權限與 Feature Flag。
• 即時通知服務需要頻繁查詢 topic 的在線訂閱者。

這類需求的陷阱是把所有慢查詢都當成快取問題。若查詢慢是因為資料模型、索引、N+1 request、外部 API timeout 或資料量爆炸，快取只能暫時吸收症狀。讀取壓力要先確認是否有明確 source of truth、資料能否重建、失效後是否能接受短暫不一致。

下一步可讀：後端服務能力地圖 與 狀態與資料儲存選型。

【判讀】非同步需求要先找 request 邊界

非同步需求的核心訊號是「使用者不需要等到所有後續工作完成」。一個 request 可以先完成主要承諾，後續工作由背景流程、queue、stream 或 outbox 接續處理。

接近真實網路服務的例子包括：

• 付款成功頁先回應使用者，email、推播與報表更新在後面完成。
• 使用者上傳影片後先看到處理中狀態，轉檔與縮圖由背景 worker 執行。
• 外部 webhook 進來後先驗證與保存，再由後續流程重試與分派。

這類需求的陷阱是把「放到背景」視為可靠性保證。背景工作離開 request 後，系統還要回答是否可遺失、是否重試、是否允許重複、是否需要順序、process 重啟後工作是否仍存在。

下一步可讀：非同步與事件傳遞選型。

【判讀】即時互動需求要先找狀態補償方式

即時互動需求的核心訊號是「client 持續在線，並期待快速看到變化」。聊天、通知、進度更新、多人協作、presence 與 dashboard 都屬於這類需求。

接近真實網路服務的例子包括：

• 客服聊天室需要把新訊息推給在線客服與使用者。
• 任務處理頁需要即時顯示轉檔進度。
• 共同編輯工具需要讓其他使用者看到狀態變化。

這類需求的陷阱是把即時通道當成唯一可靠資料來源。WebSocket、Server-Sent Events (SSE) 或 pub/sub 適合降低延遲，但 client 斷線、server 重啟、網路切換都會造成缺口。即時需求要先決定離線後如何 offline catch-up、哪些訊息可丟、哪些訊息需要正式保存。

下一步可讀：非同步與事件傳遞選型 與 操作平台選型。

【判讀】操作診斷需求要先找決策問題

操作診斷需求的核心訊號是「團隊需要用訊號做決策」。log、metric、trace、dashboard 與 alert 的用途不同；它們都應服務某個排障、容量、告警或產品營運問題。

接近真實網路服務的例子包括：

• API 延遲上升時，要判斷瓶頸在資料庫、外部 API、queue 還是某個版本。
• queue lag 增加時，要判斷 producer 變快、consumer 變慢，還是下游失敗。
• 某地區 WebSocket disconnect 增加時，要知道是 client 版本、網路入口還是部署節點問題。

這類需求的陷阱是先買平台，再補欄位語意。沒有穩定欄位、trace context、錯誤分類與 runbook，觀測平台只能保存大量難以操作的訊號。

下一步可讀：操作平台選型。

【判讀】交付與可靠性需求要先找變更風險

交付與可靠性需求的核心訊號是「系統變更本身帶來風險」。當服務需要頻繁發版、水平擴容、處理尖峰、承受下游失敗或保證回歸品質，部署平台與可靠性驗證就會變成需求的一部分。

接近真實網路服務的例子包括：

• 發版時新版本尚未 ready 就接到流量，造成部分 request 失敗。
• 活動流量前沒有容量證據，只能靠臨時加機器。
• 重要 parser 一次更新後影響大量 webhook，缺少 fuzz 或回歸案例。

這類需求的陷阱是把可靠性視為上線後的補救工作。交付與可靠性要在設計時就定義 readiness、shutdown、rollback、load test、資料 migration 與事故演練的檢查點。

下一步可讀：操作平台選型。

規模成長路線下一站 → 10.1 服務拆分與邊界判讀：需求分類完之後、第一個判讀通常是「該不該把服務拆開」。若讀者剛從影片進來想學「能跑 → 能撐」演進、回到 _index 規模成長路線 看完整路徑。

小結

後端需求分類要先拆問題，再談服務。狀態保存、讀取壓力、非同步工作、即時互動、操作診斷、服務交付與可靠性驗證各自有不同判斷訊號。需求形狀清楚後，後續才進入資料庫、快取、queue、觀測平台與部署平台的能力比較。

進入需求分類之前、先確認一個更早的判斷：這個服務值得自建嗎。差異化在商品、內容或服務品質、需求落在 Wix / Shopify、Google Apps Script、Firebase、WordPress 這類現成平台標準域的業務、託管形態可能是成本上更誠實的起點；判讀方式與可遷出保險見 0.21 交付形態選型、日後升級自建 tripwire 觸發的遷出執行見 10.3 託管形態遷出。本模組其餘章節預設自建已成立。

本模組先建立跨分類的選型語言。後續進入 database、Redis、message queue、observability 或 deployment 資料夾時，每個資料夾開頭都應延續同一個形式：先說明這類服務解決什麼問題，再比較同質服務的差異，最後才進入實作細節。

閱讀本模組前，建議先把 前置知識卡片 當成共同詞彙索引。選型文章會使用 consumer lag、dead-letter queue、replay、降級、停機、readiness 等概念；這些概念的完整 domain knowhow 放在卡片中，章節本文則專注於需求判讀與服務能力取捨。

章節列表

服務拆分判讀（原 0.18）與執行 Runbook（原 0.20）已移到 模組十：系統演進與遷移 — 設計階段的選型判讀留本模組、執行階段的高風險變更收斂到模組十。

需求討論順序

這個討論順序預設自建已成立；交付形態的判讀見本頁開頭的分流與 0.21 交付形態選型。

後端選型討論的核心順序是先問「問題長什麼樣」，再問「哪種能力能解決」。討論一開始就跳到產品名稱，容易把資料庫、快取、queue、觀測平台或部署平台當成固定答案；比較穩定的做法是先確認下列事項。

1. 需求類型：這是狀態保存、讀取加速、非同步處理、即時推送、診斷、交付，還是可靠性驗證問題？
2. 流量形狀：流量是穩定、尖峰、長尾、單一 hot key，還是週期性批次？
3. 資料生命週期：資料是否長期存在、能否重建、是否需要 audit、保留多久？
4. 失敗代價：延遲、重複、遺失、短暫不一致、停機，各自會造成什麼產品後果？
5. 成本模型：目前瓶頸來自雲端費用、人力維護、事故風險、開發速度，還是操作複雜度？
6. 定位與備援：錯誤發生時能否分類、追蹤、降級、切換與恢復？
7. 安全邊界：誰能存取哪些資料、資料如何遮罩、傳輸如何保護、操作如何稽核？

這些問題回答清楚後，服務分類才會自然出現。正式狀態通常走向資料庫；重複讀取通常走向快取；request 外的可靠工作通常走向 queue 或 outbox；看不見系統行為通常走向 observability；部署與擴容不穩通常走向 platform；失敗前驗證不足通常走向 reliability pipeline。

選型文章的共同格式

每篇選型文章都使用同一個閱讀路徑：

1. 核心原則：先說明這類服務解決哪一種工程問題。
2. 可觀察訊號：列出怎麼從產品需求、流量型態或事故症狀辨識問題。
3. 現實例子：用接近真實網路服務的例子建立判斷錨點。
4. 候選服務類型：列出同質服務或相近能力的差異。
5. 成本權衡：討論資安限制、流量穩定性、伺服器成本、人力成本與機會成本。
6. 下一步路由：指向對應 backend 模組，實作細節放在後續章節。

本模組新增的需求分析章節會更早一層：它們負責討論「該問哪些問題」。服務分類章節則負責討論「問題落到哪種後端能力」。

服務實體的固定討論段落

服務實體章節的核心要求是每個選型都要回答「值得引入的理由」與「引入後的代價」。討論 PostgreSQL、Redis、RabbitMQ、Kafka、Prometheus、Kubernetes、WAF、IAM、Secret Management 或任何具體服務時，都必須保留成本權衡段落。

這個段落要同時看五個方向：

1. 資安限制：權限分級、資料遮罩、傳輸保護、密鑰管理、稽核與伺服器防護會增加哪些設計與操作要求。
2. 流量與穩定性：尖峰、hot key、長連線、大量資料、重試風暴或下游失敗會讓服務承擔哪些容量壓力。
3. 伺服器與雲端成本：儲存、運算、網路傳輸、保留期限、備援、跨區與觀測資料會如何增加成本。
4. 人力與操作成本：維護、升級、監控、備份、演練、on-call、文件與事故處理需要誰負責。
5. 機會成本：選擇完整平台會延後哪些產品工作；選擇簡單方案會留下哪些風險；哪些條件會讓團隊需要重新評估。

和語言教材的關係

語言教材負責教「如何隔離外部能力」。Backend 選型模組負責教「什麼能力值得被隔離」。例如 Go 章節會說明 repository port、publisher port、cache interface 與 observability boundary；本模組則說明何時需要資料庫、Redis、broker、OpenTelemetry 或部署平台能力。

企業選型案例補充

模組零的案例補充重點是「企業如何說明選型取捨」。閱讀時先抓它在解什麼需求壓力，再對照本模組的需求分類與成本取捨章節。

若要做「跨產業 × 跨規模」的系統化案例蒐集與回寫，直接使用 0.14 企業選型案例圖譜；該章節提供分組後案例地圖與覆蓋缺口檢查表，可直接當後續補強 backlog。

本模組不處理

本模組只處理需求分析與選型入口。具體 SQL schema、Redis command、RabbitMQ exchange、Prometheus query、Kubernetes deployment 或 chaos test 設計，會放在後續對應模組中。

實作探討入口

當你準備從概念層切到實作層，建議先選一條單一業務路徑做最小切片，並同時建立三個 artifact：

1. 觀測證據： 4.20 Observability Evidence Package
2. 驗證證據： 6.23 Verification Evidence Handoff
3. 事故決策： 8.19 Incident Decision Log

這三個 artifact 先接起來，再補該路徑的 DB、cache、queue、deployment 細節，實作討論會更穩定，也更容易做跨模組回寫。

完整撰寫順序與服務路徑選擇依 Backend 學習路線 安排。

大綱待辦

這一節只記錄仍需要沿著原子卡原則拆出的概念，之後補卡、拆卡或新增卡都先回到這裡確認。

已完成拆分

• endpoint：service endpoint / public API endpoint / admin endpoint / diagnostic endpoint / internal endpoint
• gateway：API gateway / request routing
• contract：boundary contract / API contract / deployment contract / queue contract / load balancer contract
• protocol：communication protocol / request-response protocol / message protocol / webhook protocol
• adapter：integration adapter / repository adapter / provider adapter / notification adapter
• middleware：request middleware / authentication middleware / authorization middleware / observability middleware / security middleware / validation middleware

需要保留為議題入口的章節

• 0.0 後端需求分類地圖
• 0.1 後端服務能力地圖
• 0.2 狀態與資料儲存選型
• 0.3 非同步與事件傳遞選型
• 0.4 操作平台選型
• 0.5 流量與資料量評估
• 0.6 成本、風險與選型取捨
• 0.7 錯誤定位、觀測訊號與備援切換設計
• 0.8 資安與資料保護需求
• 0.9 知識網：訊息與事件決策路徑
• 0.10 知識網：容量、觀測與資安決策路徑
• 0.11 攻擊者視角（紅隊）：跨服務弱點判讀總表
• 0.12 觀測、可靠性與事故服務選型
• 0.13 操作控制 vertical slice 實作入口
• 0.14 企業選型案例圖譜
• 0.19 雲端服務對照地圖（AWS / GCP / Azure）