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

同一個元件在不同需求下的設計不同。售票系統可以讓大多數請求在進資料庫之前就收到「售完」，交易撮合每一筆被接受的委託都要處理；剛建立的短網址轉址讀到幾秒前的舊資料沒有影響，checkout 的付款狀態讀到舊資料會讓使用者重複付款。每個系統都有一件必須一次只處理一筆的事，它的互斥範圍（哪些請求彼此必須輪流處理，定義在 9.0 請求路徑上的負載分析 的〈一次一筆的處理與它的互斥範圍〉）各自不同：售票是同一張票（座位）的認領與訂單狀態，撮合是同一個交易對的整本委託簿，checkout 是同一筆訂單的付款狀態，短網址是同一個代碼的分配。

四個系統共用幾個部署上的前提：都在一個雲端帳號的一個區域裡（短網址是一台主機），有人值班接告警；售票的等候室自建、一次只有一個場次開賣；撮合的用戶端以程式為主，市場是連續撮合。前提不同時，各篇裡依賴它的那幾段會標出來。

短網址服務

短網址服務把一個長網址換成一段短代碼，使用者打開短網址時，服務回 301 或 302 轉址到原本的長網址。請求有三種：轉址（以代碼查出長網址，不需要登入）、建立與管理短網址（登入之後建立、修改、停用自己的短網址），以及管理者的後台操作（停用被檢舉的短網址、查看帳號）。轉址的量遠大於其他兩種，示意的比例是轉址與建立一百比一。

不能讓步的需求：轉址的目標必須是短網址目前登記的那一個長網址；寫錯的轉址會把使用者送到錯的網站，而主機、容器與請求的監控數字都正常。代碼不能重複分配給兩個長網址。帳號只能修改自己的短網址。管理者停用一個被檢舉的短網址之後，要在幾分鐘內（示意）停止轉址，所以轉址回應的快取期限有上限。這個範例允許建立者修改目的地，修改之後要重新做惡意網址檢查並保留修改紀錄；目的地是否允許修改、撤回要多快生效，是短網址服務要先定案的需求決定，見 0.23 短網址服務的需求定義 的〈目的地修改的功能需求與風險〉與 0.24 短網址服務的實作 的〈各層快取與撤回所需的時間〉。

可以讓步的需求：剛建立的短網址在幾秒內轉址失敗，影響的是一個剛建好、還沒散出去的連結；轉址的延遲多個幾十毫秒，使用者感覺不到。點擊次數的統計可以延遲、可以少算幾筆。

規模假設（示意）：每秒數百次轉址，尖峰是平常的數倍（一則被大量轉貼的連結）；短網址總數在百萬筆的量級。

起點架構：一台主機上以 Docker Compose 跑入口 Nginx、後端程式、PostgreSQL 與 Valkey，各在一個容器裡；Valkey 快取代碼到長網址的對應。監控的分層以它為例，見 4.0 服務端監控的分層，實際的盤點見 4.0.2 以監控鏈盤點單機短網址服務。

售票搶購

售票系統在指定的開賣時間讓使用者選場次、選座位或票種、下單並在期限內付款。請求有四種：讀取場次與座位圖、排隊或取得購票資格、扣庫存下單、付款與付款結果的回呼。開賣前幾秒到開賣後幾分鐘的請求量是平常的數百倍，票賣完之後請求量迅速回落。

不能讓步的需求：不超賣，賣出的票數不能超過場次的票數，同一個座位不能賣給兩個人。付款成功的訂單一定要有票。付款期限（示意：十分鐘）到期而未付款的票要放回可售，放回與付款不能同時成立。

可以讓步的需求：使用者可以接受排隊幾分鐘，等候期間看到自己的位置即可；座位圖上的剩餘數量可以落後幾秒，因為最後的判斷在扣庫存那一步；票在開賣後的前幾秒沒有全部賣出（少賣），只要之後回收得回來，是可以接受的短暫狀態。誰先買到票的順序依業務決定（先到先得或抽籤），而不論哪一種，規則要事先公布並照做。

成功請求的總數有上限：成功的購票總數不會超過票數。十萬個帳號搶五千張票、每個帳號限購一張時（示意），票賣完那一刻，其餘九萬五千人的購票請求結果已經確定是售完（直到付款期限到期、有票被放回為止）。

規模假設（示意）：一個場次五千張票，開賣時十萬人同時在線；開賣後第一分鐘各種請求加起來每秒數萬個，其中扣庫存的請求受排隊放行的速率限制。

起點架構：CDN 與入口、無狀態的 API 服務（可水平擴充）、排隊服務、關聯式資料庫存放每張票一列與訂單、第三方金流處理付款、排程工作處理付款期限。站內的對照案例有 9.C15 拓元 Tixcraft：售票搶購的瞬間爆量架構 與 9.C16 SeatGeek：DynamoDB + Lambda 打造的虛擬等候室；負載路徑的分析，包括什麼條件下才在扣庫存前面加一道 Redis 閘門，見 9.0.1 售票搶購的負載路徑。

電商 checkout

電商的 checkout 讓使用者把購物車裡的商品下單、付款，之後由下游寄送確認信、更新庫存與報表。請求有：讀取商品與價格、建立訂單、送出付款、接收金流業者的付款結果回呼；訂單建立之後的通知、出貨與報表由訊息佇列的消費端非同步處理。這是 Backend 教材的閱讀路線 裡貫穿各模組的 checkout 流程。

不能讓步的需求：同一筆訂單只能扣款一次，使用者重按付款或用戶端重試都不能多扣；付款成功的訂單不能遺失；訂單金額必須等於使用者確認時看到的金額。

可以讓步的需求：確認信晚幾分鐘寄出、報表晚一小時更新，使用者與營運都能接受；商品頁的價格快取可以落後，只要下單時以資料庫的價格重新計算並在金額不同時請使用者確認。

成功請求的總數沒有固定上限：庫存充足時，每一個下單請求都可能成交，擋掉一個就是少一筆營收。

規模假設（示意）：平日每秒數十筆訂單，促銷活動時是平常的十倍；商品頁的讀取是下單的數百倍。

起點架構：Kubernetes 上的商品、訂單與付款服務，PostgreSQL 存放訂單，Redis 快取商品與價格，訊息佇列連接訂單服務與通知、出貨、報表的消費端，付款服務呼叫第三方金流並接收回呼。監控的盤點見 4.0.3 以監控鏈盤點 Kubernetes 上的電商 checkout。

交易撮合

交易撮合系統接收買方與賣方的委託，在委託簿裡配對成交。交易對（trading pair）是一組可以互相交易的資產，例如 BTC 對 USD；委託簿（order book）是一個交易對上還沒成交的買賣委託，依價格與時間排成的清單；撮合依價格與時間的優先順序（price-time priority：價格較好的先成交，同價格時先到的先成交；CME 的文件稱這條規則為 FIFO）把新進的委託與簿上的對手配對。成交之後，系統送出成交回報給雙方，更新雙方的部位（position，帳戶持有的各項資產數量），並把行情（最新成交價、各價位的委託量）送給訂閱者。請求有：送出委託、取消委託、查詢帳戶與委託狀態、訂閱行情。

不能讓步的需求：每一筆被接受的委託都要處理，處理不了的要在接受之前明確拒絕；處理的順序必須與到達撮合引擎的順序一致，因為順序決定誰成交；同一筆委託不能執行兩次；已回應「已接受」的委託不能遺失。

可以讓步的需求：行情送給處理不及的訂閱者時，可以合併中間的報價更新只送最新的狀態；帳戶的歷史查詢可以讀稍舊的副本。

延遲改變請求的價值：在連續撮合的市場裡（委託一到就與簿上的對手配對），一筆委託在佇列裡多等一秒，送進委託簿時市場已經不是使用者下單時的市場。市價單會以偏離預期的價格成交；限價單不會比限價差，代價是掛著的價格已經過時、在市場變動後被以不利的時機成交。

規模假設（示意）：一個熱門交易對每秒數萬筆委託與取消，市場劇烈波動時是平常的十倍以上；撮合的延遲目標在毫秒以下。

起點架構：入口閘道（驗證身分、檢查餘額與帳戶的速率限制）、依交易對分開的撮合引擎、委託先寫入依序編號的日誌再撮合、行情發布服務、帳戶與歷史資料存放在資料庫。站內的對照案例有 9.C3 Coinbase International Exchange：超低延遲交易的逆向容量設計，負載路徑的分析見 9.0.2 交易撮合的負載路徑，監控的盤點見 4.0.4 以監控鏈盤點交易撮合系統。

四個系統在請求性質上的差別

四個系統在下面三個性質上的位置。第一欄只對要經過那件一次一筆處理的請求有意義（購票、下單、委託、建立短網址），轉址、查商品這類讀取不在其中：

三個性質怎麼用來判斷負載保護的方向（第一欄只是可提早回應的比例的一個來源，拍賣就是有上限而比例低的反例；第二欄要以「改變、所以要拒絕」判讀，還要請求處理時不再經使用者確認），在 9.0 請求路徑上的負載分析。延遲改變請求價值的系統不只連續撮合的交易所。廣告的即時競價要在交易平台設定的期限內回出價（期限以毫秒計，各平台不同），晚到的出價直接作廢；叫車的媒合晚了幾秒，司機與乘客的位置都變了。同一個請求被處理兩次有後果的系統，從用戶端到資料庫的每一段都要能辨認重送的請求（Idempotency）。可提早回應的比例與延遲這兩個性質，加上互斥範圍能縮小到什麼程度，如何決定負載保護的方向，是 9.0.1 售票搶購的負載路徑 與 9.0.2 交易撮合的負載路徑 對照的主題：售票的比例高（成功請求的總數有上限，售完之後的請求結果已確定）、延遲不改變價值，撮合兩者都相反。