Writing archive · 344
文章索引
記錄系統設計、AI Agent 工作流，以及實際專案裡值得保留的技術取捨。
購物車有一件缺貨，已扣的其他庫存怎麼辦？
把單品項訂單擴為多品項後，選擇先鎖定並檢查全部庫存，再共同預留。沿著缺貨、反向取鎖與逾時的順序，釐清如何整單拒絕、保留冪等收據，又不留下半套扣庫存。
評估器說 PASS，還不足以讓 Agent 過關
把 evaluator 的分數、判決門檻與機率校準拆開。從錯放與誤擋的示意案例，建立不放寬底線、不洩漏驗證資料的 Agent 驗收流程。
退款服務越慢，重試越要共用同一份額度
從退款 worker 不斷重送的案例，決定首次呼叫、重試與結果核對如何共用外呼預算。區分每秒發送量、在途上限與積壓時間，讓下游恢復時有機會追上待辦。
退款已完成，重新整理卻又變成處理中？
沿著一筆退款狀態回退的案例，決定哪些訂單查詢可以讀快取、哪些必須讀主庫。把新鮮度寫成讀取契約，再衡量省下的資料庫成本。
退款待辦只拿 20 筆，為什麼資料庫仍然越查越慢？
從退款 worker 的一條查詢，決定複合索引的欄位順序、到期排序與驗收資料分布。LIMIT 限制回傳數量，不能代替掃描成本的證據。
訂單取消後才收到付款成功，這筆錢仍然要入帳
取消已經釋放庫存，晚到的付款通知卻證實收款成功。用同一張訂單拆開收款事實與履約資格，決定何時留下退款待辦，以及為什麼不能把訂單改回已付款。
下單逾時後，靠同一筆交易的收據決定能不能重試
把下單冪等收據、訂單與庫存預留放進同一筆 MySQL 交易，釐清唯一鍵競爭、提交結果不明與舊鍵重送的處理方式。
每秒 20 次下單需要幾台機器？先把容量寫成可驗證的預算
延續小型訂單案例，分開估算 HTTP 嘗試、唯一操作、在途請求、資料庫連線與儲存成長，選出模組化單體的首輪壓測規格，並用熱點與重試反例決定何時擴容。
下單已回滾，庫存卻沒回來：模組必須共用同一筆交易
沿用單倉訂單案例，把資料寫入責任與交易協調分開：模組擁有資料規則，下單用例管理同一條 MySQL 連線，並用失敗注入驗收邊界。
下單 API 很快，客人卻買不到：成功回覆到底承諾了什麼？
用虛構小型訂單案例，把建立成功、重試、缺貨與逾時拆成業務契約、不變量及可量測 SLO，再比較同步成立與非同步受理。附可執行的合成驗收與設計練習。