這篇整理一個已經能跑的服務，在流量與業務長大之後會依序撞上哪些限制、每一種限制要補哪一塊能力，以及 Backend 教材裡對應的章節。範圍從一臺機器開始，到多區域、多服務為止；還沒把服務做出來的讀者，先走閱讀路線裡「沒部署過服務」或「API 到資料流」那兩條。

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

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

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

這條路線和閱讀路線裡的「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 說成物料配送）。比喻傳達的是形狀，操作時需要的是工程術語與判斷條件，下表把常見的影片用詞接到對應的章節：