這篇整理 Backend 教材各模組之間的閱讀順序：教材分成哪幾層、依讀者手上的目的各走哪一條路線，以及一條把各模組串起來的 checkout 流程。範圍是模組之間的順序，每個模組內部的章節順序在該模組的列表頁。

Backend 教材的分層：分類語言、服務路徑與具體工具各自回答的問題

Backend 教材把後端服務能力分成三層來教。分類語言讓讀者知道資料、快取、事件、觀測、部署、驗證、資安、事故與容量各自承擔什麼責任；服務路徑用一條具體業務流程，演練這些能力之間怎麼交接；具體工具討論 PostgreSQL、Redis、Kafka、Kubernetes、PagerDuty、k6 這些服務落到真實操作時的能力、成本與遷移。

層回答的問題從哪裡讀起
分類語言這是哪一類問題後端服務選型模組與前置知識卡片
服務路徑一個服務流程怎麼把多個能力接起來資料庫到容量規劃各模組的主章，加上本篇下方的 checkout 流程
具體工具要選哪個工具、怎麼遷移各模組的 vendors/ 子目錄；案例庫在資安與資料保護模組與效能工程與容量規劃模組

三層的順序是理解的順序：分類語言先建立，服務路徑才有詞彙可以描述交接，具體工具的比較才有一個分類責任可以回扣。已經懂分類、只想比較工具的讀者可以直接從具體工具那一層進來，遇到工具頁回扣分類責任的段落時，再回到分類語言那一層補那一類的定義。

依讀者目的排的閱讀路線：從沒部署過服務到規模成長

下表每一列是一種讀者目的。建議順序欄的箭頭是閱讀先後，讀完那一欄說的是走完之後能做出的判斷。

路線適合讀者建議順序讀完能做什麼
沒部署過服務會寫程式、但沒把服務上線過服務上線：部署、主機形態、域名與 HTTPS、十二要素、自架或託管、備份與還原（部署是什麼 → 主機形態 → 域名與 HTTPS → 自架或託管 → 備份）→ 回到後端服務選型模組做選型能把一個服務從本機推上線，並知道接著補哪一塊
系統心智模型想理解後端服務怎麼分工0.21 交付形態選型：從全託管到自建的光譜與邊界 → 後端服務選型模組 → 前置知識卡片 → 資料庫、快取與訊息佇列三個模組的共同觀念 → 10.1 服務拆分與邊界判讀、0.19 雲端服務對照地圖（AWS / GCP / Azure）、9.13 擴展軸與 Stateless 前提能把需求分類成正式狀態、暫存副本、非同步交接、觀測、部署或可靠性問題，並用服務邊界與擴展軸描述系統往哪裡走
API 到資料流想設計 API 的對外契約，以及它背後的資料與事件流程API 設計與對外契約模組 → 資料庫與持久化模組 → 1.13 應用層查詢反模式與 Query 預算 → 快取與 Redis 模組 → 訊息佇列與事件傳遞模組 → 可觀測性平台模組的證據整理 → 1.14 Production Slow Log Closed Loop能說明一次 checkout 怎麼跨資料庫、快取、佇列與證據整理，並在上線前用 query 預算與 slow log 攔下查詢反模式
Production 操作想學上線、觀測、驗證與事故的閉環可觀測性平台模組 → 部署平台與網路入口模組（含 5.9 邊緣分發與靜態資源（CDN / Origin Protection））→ 可靠性驗證流程模組 → 事故處理與復盤模組能把 release、alert、gate、邊緣層的 origin protection、事故決策紀錄與事後回寫串成操作閉環
資安與資料保護想理解權限、秘密、資料、偵測與回應資安與資料保護模組 → 可觀測性平台模組的稽核證據 → 可靠性驗證流程模組的控制驗證 → 8.17 Security Incident vs Operational Incident 分流 → 8.25 建置主機被入侵後的根除與重建能從身份、資料、入口、秘密與稽核證據判讀控制面
工具比較與遷移已懂分類、要比較工具或規劃遷移對應模組的主章 → 0.19 雲端服務對照地圖（AWS / GCP / Azure） → 該模組的 vendors/ → 遷移操作手冊（含 10.2 服務拆分執行 Runbook（Strangler Fig / 雙寫期 / 切流 / 回退）、10.3 託管形態遷出：資產線盤點與並行期執行）→ 案例（含 1.14 Production Slow Log Closed Loop、9.14 連線池放大解法（PgBouncer / RDS Proxy / ProxySQL））能先判斷分類責任，再對照雲端能力、比較具體服務、操作成本與遷移風險
規模成長已經做出能跑的服務，要學讓它撐住服務規模成長的閱讀路線：架構撞到限制的訊號、要補的能力與對應章節，那一篇有完整的閱讀順序與各訊號對應的章節能描述一個服務從一臺機器演進到多區域多服務的過程、每一段會撞上什麼、要先補哪一塊能力

各條路線共用同一組後端詞彙，所以可以只走一條，也可以從系統心智模型那一條開始，再依工作需求轉進其他路線。表格裡帶編號的連結是單篇文章，只寫模組名的連結是整個模組。

貫穿各模組的 checkout 範例流程與各模組處理的問題

各模組可以獨立閱讀，而讀者需要一個共同的場景，才看得出某一章處理的是整個服務的哪一段。Backend 教材用一條簡化的 checkout 流程當這個場景（這個 checkout 與另外三個範例系統的功能、需求與規模假設見 Backend 範例系統）：使用者建立訂單、付款服務回應、商品或價格資料被快取、事件送到下游的通知與報表、服務上線時產出觀測與驗證證據、事故發生時留下決策紀錄並回寫改善。

這條流程在演進中會遇到下面這些問題，每一個問題需要好幾個模組一起處理：

問題一起處理的模組產物
訂單表新增付款狀態欄位資料庫、可觀測性、事故處理遷移計畫、驗證查詢、出事時的決策路徑
商品價格快取失效，回源流量要保護快取、可觀測性、可靠性驗證快取證據、origin protection gate、預熱計畫
訂單事件的 consumer 失敗，要重播訊息佇列、可靠性驗證、事故處理冪等證據、死信佇列的處理方式、重播 runbook
Checkout 服務發版部署平台、可觀測性、事故處理發版計畫、canary 證據、drain 訊號、回滾條件
付款供應商的逾時設定變更可靠性驗證、可觀測性、效能與容量release gate、SLO 證據、容量基準
Webhook 的 secret 輪替資安與資料保護、可觀測性、事故處理影響範圍圖、稽核證據、回滾視窗
限時搶購的高峰準備效能與容量、快取、訊息佇列、可靠性驗證負載模型、飽和證據、佇列與快取的容量 gate

讀到資料庫模組時，它處理的是訂單表欄位演進那一段；讀到訊息佇列模組時，它處理的是訂單事件在程序之間的交接；讀到事故處理模組時，它收斂的是欄位演進、事件重播、發版與 secret 輪替這幾個問題出事之後的決策與回寫。