資料一致性
8 篇文章
新訂單必填配送時段，舊訂單的空值該怎麼辦？
新增配送偏好時，分開處理尚未詢問的舊訂單與已明確選擇的新訂單。以相容版本、功能開關及履約快照安排上線順序，避免預設值捏造顧客選擇。
地址剛改好，倉庫卻寄到舊家：出貨資料在哪一刻凍結？
替已付款訂單定義改址截止點：地址修改與本地派工共用訂單列鎖，將地址版本、不可變派工快照與交付待辦一起提交，避免舊頁覆寫與倉庫讀到另一份地址。
結帳顯示 500 元，送單時變 550 元：報價在哪一刻到期？
替購物車加入不可變的伺服器報價，明確選擇取得報價鎖後的受理時間作為期限判斷點。區分新購買與原操作重放，讓到期、變價與回覆遺失都不會改寫已成立訂單。
購物車有一件缺貨，已扣的其他庫存怎麼辦？
把單品項訂單擴為多品項後，選擇先鎖定並檢查全部庫存，再共同預留。沿著缺貨、反向取鎖與逾時的順序，釐清如何整單拒絕、保留冪等收據，又不留下半套扣庫存。
退款已完成，重新整理卻又變成處理中？
沿著一筆退款狀態回退的案例，決定哪些訂單查詢可以讀快取、哪些必須讀主庫。把新鮮度寫成讀取契約，再衡量省下的資料庫成本。
退款工作已被接手，舊 worker 還能把結果寫回嗎？
退款工作交接後，遲到的程序可能覆寫新結果。用 MySQL 短交易與 attempt 條件更新界定寫入權，並說清楚租約到期為何只能啟動接管，不能證明遠端沒有退款。
銀行間清算與對帳系統（Reconciliation & Settlement Engine）：三方對帳矩陣、T+1 清算管線與自動沖正補償
深度剖析金融系統核心生命線：如何保證千億級資金流轉的分毫不差？三方對帳矩陣（內部帳本 vs. 支付網關 vs. 銀行清算文件）、T+1/T+0 分散式對帳管線、長尾差錯帳（Discrepancies）處理與自動沖正補償機制實戰。
五大分散式快取讀寫模式：Cache-Aside、Read-Through、Write-Through、Write-Behind 與延遲雙刪實戰
深入剖析現代分散式快取架構的五大讀寫模式：Cache-Aside、Read-Through、Write-Through、Write-Behind（非同步批量回寫）與 Refresh-Ahead、快取與資料庫雙寫一致性難題、延遲雙刪（Delayed Double Deletion）與 Binlog CDC 非同步淘汰最佳實踐。