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

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

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

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

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

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

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

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

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

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

各個決定的內容、決錯之後的症狀與機制所在的篇章

決錯之後的症狀有一個共同點：查詢照跑而答案不對。 只有兩個決定決錯時會當場出聲：量代價決錯時查詢慢得看得出來；交付時換了引擎，有一類差異第一次執行就報錯。SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機 把跨引擎的差異按發聲的位置分級，第一次執行就報錯的叫當場報錯，其餘的差異要麼等某一筆資料才報錯、要麼始終靜默。其餘的決定決錯時欄位正常、列數合理，沒有任何東西提示要去檢查。

最常被跳過的決定：追問需求、設定判斷標準與對邊界

追問需求與設定判斷標準。 這兩個決定發生在打開編輯器之前，所以不留下任何痕跡——跳過了的查詢跟沒跳過的長得一模一樣。而跳過追問需求的代價是整段查詢答錯題，跳過設定判斷標準的代價是後面每一次修改都不知道有沒有改好。

對邊界。 一句需求描述的是資料正常時的樣子，而正式資料裡會出現提出需求的人沒想到、所以沒說的情形。以「哪幾天氣溫比前一天高」為例：同一個測站同一天有兩筆紀錄（感測器重送、補登、換設備之後兩套系統各寫一筆）、觀測日存的是哪一個時區的日期、三個月後才補進來的舊資料讓昨天的答案今天變了、同一個測站代號在某一天之後指向另一個地點。對邊界這個決定，就是在查詢寫好之後把這些情形逐一列出來，並決定每一種出現時查詢該回什麼。

這份清單沒有地方可以查。需求裡沒有它，schema 也只記下有哪些欄位、各是什麼型別，不記下資料在現實中會怎麼偏離預期。列得出幾種，取決於看過多少這個領域的資料：看過感測器重送，才會想到同一天可能有兩筆；看過補登，才會想到歷史答案會變。所以這一步的能力靠經驗累積，每在正式資料上遇到一種新的情形，就把它加進這個領域的查詢的檢查清單。

跳過它的症狀最難察覺：查詢在大部分資料上都對，只在碰到那幾筆特殊資料時算錯，而且不報錯。那幾筆往往要到有人拿結果去對帳，才被發現。

決定的前提：建表時定下的表的形狀

從追問需求到交付，每一個決定都做在一組已經建好的表上，而表的形狀是建表時的決定造出來的：欄位允不允許為空、鍵唯不唯一、長欄位放哪一張表、常一起取的資料切在幾張表、字串的比較規則寫在哪一層、外鍵生不生效。選寫法、補前提的時候，鍵唯不唯一、欄位允不允許為空已經定了；量代價的時候，長欄位放哪一張表、常一起取的資料切在幾張表也已經定了。這些建表時的決定替往後每一段查詢定了價——手上要交的是一份 schema 設計而不是一段查詢時，問題落在追問需求之前。以鍵唯不唯一為例：「哪幾天氣溫比前一天高」用自連接、視窗函數與相關子查詢三種寫法，共同押的前提，是同一個測站同一天只有一筆；表上有 UNIQUE (測站, 觀測日) 時這個前提由資料庫保證，沒有的話每一段查詢都得自己處理重複，否則自連接會把一列配成多列。每一個決定各自替查詢定了什麼代價，實測在 backend 1.16 Schema 設計決定的查詢代價。

在「哪幾天氣溫比前一天高」這句需求上做完全部決定的示範

SQL.22 查詢設計的完整示範：把「哪幾天氣溫比前一天高」從需求做到上線 拿「哪幾天氣溫比前一天高」這句需求從頭做完這些決定：把「前一天」追問成日曆上的前一天還是資料上的前一筆；用自連接、視窗函數與相關子查詢各寫一次，找出三者共同押的前提（同一個測站同一天只有一筆）；看漏掉相隔天數與漏掉分區的兩個錯誤版本：漏掉相隔天數的多報，漏掉分區的錯在哪個方向要看同一天兩個測站誰排在前面；把自連接再分成日期差與等值兩種寫法，在同一組資料上量這兩種自連接、視窗函數與相關子查詢的時間，差到三個量級，其中一種加了索引反而變慢；最後列出重複紀錄、時區、補登與測站搬家這幾種需求沒說的情形。

架構調整的時機與架構撞到限制的訊號

服務的架構會長出新的部分，是因為現有的形狀承受不了某一種壓力，而那種壓力在監控或使用者回報裡有一個可辨認的樣子，本篇稱它為架構撞到限制的訊號：單一服務承載不了業務分化、單機規格撞到天花板、應用層的查詢變慢、單一資料庫成為瓶頸、源站被流量打爆、同步呼叫卡住整條交易流程、可預期的活動高峰需要事前準備。

所以這一組章節的讀法是先認出手上是哪一種訊號，再讀那一種訊號對應的能力，而不是照模組編號順讀。同一個訊號過早處理，付的是用不到的複雜度；過晚處理，付的是事故。

這條路線和閱讀路線裡的「API 到資料流」分工不同：那一條教怎麼把功能做出來，這一條教做出來之後怎麼撐住。兩條可以分開讀，也可以寫完第一個 MVP 之後回到這一篇盤點。MVP 如果是用託管平台或 BaaS 做的，先用 0.21 交付形態選型：從全託管到自建的光譜與邊界 的升級自建 tripwire 判斷該不該啟動自建評估；評估成立的話，遷出的執行在 10.3 託管形態遷出：資產線盤點與並行期執行，遷入之後再照下面的訊號走。

各種架構撞到限制的訊號與要補的能力

表格由上往下大致是一個服務撞到這些訊號的常見先後，而先後不是固定的：有的團隊在單機容量用完之前就先拆服務，有的團隊一直不需要拆。源站被打爆之後如果還要應付可預期的活動高峰（雙 11、新片上線、推廣活動），加讀 9.11 高峰事件準備；平日的容量規劃在 9.6 容量規劃模型。

規模成長路線從頭讀的章節順序

要把整條路線從頭讀一次，順序是：0.21 交付形態選型：從全託管到自建的光譜與邊界的升級 tripwire → 0.0 後端需求分類地圖 → 10.3 託管形態遷出：資產線盤點與並行期執行（從託管平台出身的服務才需要）→ 10.1 服務拆分與邊界判讀 → 9.13 擴展軸與 Stateless 前提 → 1.13 應用層查詢反模式與 Query 預算 → 1.1 高併發下的 SQL 讀寫邊界 → 2.2 cache aside 與失效策略 → 5.9 邊緣分發與靜態資源（CDN / Origin Protection） → 訊息佇列與事件傳遞模組 → 9.11 高峰事件準備。

這個順序把判斷放在動手之前：先確認要不要自建、需求屬於哪一類、邊界在哪裡，再依擴展、查詢、讀取、邊緣、非同步、高峰的次序補能力。各篇結尾的「規模成長路線下一站」指的就是這個順序裡的下一篇。

入門影片用詞與 Backend 教材章節的對照

講 SaaS 擴展的入門影片常用生活比喻解釋這些概念（把快取說成保溫桶、把 CDN 說成物料配送）。比喻傳達的是形狀，操作時需要的是工程術語與判斷條件，下表把常見的影片用詞接到對應的章節：