系統設計每日實戰
本系列依難度與架構脈絡由淺入深編排，建議依章節序號循序閱讀。
下單 API 很快，客人卻買不到：成功回覆到底承諾了什麼？
用虛構小型訂單案例，把建立成功、重試、缺貨與逾時拆成業務契約、不變量及可量測 SLO，再比較同步成立與非同步受理。附可執行的合成驗收與設計練習。
每秒 20 次下單需要幾台機器？先把容量寫成可驗證的預算
延續小型訂單案例，分開估算 HTTP 嘗試、唯一操作、在途請求、資料庫連線與儲存成長，選出模組化單體的首輪壓測規格，並用熱點與重試反例決定何時擴容。
下單已回滾，庫存卻沒回來：模組必須共用同一筆交易
沿用單倉訂單案例，把資料寫入責任與交易協調分開：模組擁有資料規則，下單用例管理同一條 MySQL 連線，並用失敗注入驗收邊界。
下單逾時後，靠同一筆交易的收據決定能不能重試
把下單冪等收據、訂單與庫存預留放進同一筆 MySQL 交易，釐清唯一鍵競爭、提交結果不明與舊鍵重送的處理方式。
訂單取消後再重試，別把別人的庫存還回去
沿用單倉訂單案例，以 MySQL 同一交易中的預留狀態轉移，處理重複取消、補庫存失敗與提交結果不明；並界定付款、出貨加入後必須重訂的規則。
訂單取消後才收到付款成功，這筆錢仍然要入帳
取消已經釋放庫存，晚到的付款通知卻證實收款成功。用同一張訂單拆開收款事實與履約資格，決定何時留下退款待辦，以及為什麼不能把訂單改回已付款。
退款待辦只拿 20 筆，為什麼資料庫仍然越查越慢？
從退款 worker 的一條查詢，決定複合索引的欄位順序、到期排序與驗收資料分布。LIMIT 限制回傳數量，不能代替掃描成本的證據。
退款已完成，重新整理卻又變成處理中？
沿著一筆退款狀態回退的案例，決定哪些訂單查詢可以讀快取、哪些必須讀主庫。把新鮮度寫成讀取契約，再衡量省下的資料庫成本。
退款服務越慢，重試越要共用同一份額度
從退款 worker 不斷重送的案例，決定首次呼叫、重試與結果核對如何共用外呼預算。區分每秒發送量、在途上限與積壓時間，讓下游恢復時有機會追上待辦。
退款工作已被接手，舊 worker 還能把結果寫回嗎？
退款工作交接後，遲到的程序可能覆寫新結果。用 MySQL 短交易與 attempt 條件更新界定寫入權，並說清楚租約到期為何只能啟動接管，不能證明遠端沒有退款。
購物車有一件缺貨，已扣的其他庫存怎麼辦？
把單品項訂單擴為多品項後，選擇先鎖定並檢查全部庫存，再共同預留。沿著缺貨、反向取鎖與逾時的順序，釐清如何整單拒絕、保留冪等收據，又不留下半套扣庫存。
結帳顯示 500 元，送單時變 550 元：報價在哪一刻到期？
替購物車加入不可變的伺服器報價，明確選擇取得報價鎖後的受理時間作為期限判斷點。區分新購買與原操作重放，讓到期、變價與回覆遺失都不會改寫已成立訂單。
地址剛改好，倉庫卻寄到舊家：出貨資料在哪一刻凍結？
替已付款訂單定義改址截止點：地址修改與本地派工共用訂單列鎖，將地址版本、不可變派工快照與交付待辦一起提交，避免舊頁覆寫與倉庫讀到另一份地址。
物流通知晚到時，怎麼避免訂單狀態倒退？
用明確的配送進度轉移與獨立待核對標記，處理重複、亂序及退件通知。保留事件、鎖定同一份派工資料，讓晚到的運送中不會蓋掉已確認的送達回報。
訂單明細 API：如何限制顧客只能讀自己的訂單
登入成功後，訂單明細仍要檢查所有權。用可信的顧客身分限定 MySQL 查詢，對照集中 Policy 的取捨，再用跨帳號、快取與帳號切換案例驗收。
新訂單必填配送時段，舊訂單的空值該怎麼辦？
新增配送偏好時，分開處理尚未詢問的舊訂單與已明確選擇的新訂單。以相容版本、功能開關及履約快照安排上線順序，避免預設值捏造顧客選擇。
訂單資料庫還原了，什麼時候才能重新接單？
付款已完成，還原後的訂單卻回到未付款。用一次虛構故障決定恢復服務的放行條件，核對外部結果、遺失的冪等收據與庫存，再衡量停寫和分區恢復的代價。
退款一直沒完成，為什麼延遲圖卻很好看？
若只在退款完成時記錄耗時，卡住的案件可能完全消失在圖表外。從持久未決紀錄計算等待年齡，連同觀測器的新鮮度一起告警，讓人工接手期限有可驗證的依據。