<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>資料不一致 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E8%B3%87%E6%96%99%E4%B8%8D%E4%B8%80%E8%87%B4/</link><description>Recent content in 資料不一致 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 23 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E8%B3%87%E6%96%99%E4%B8%8D%E4%B8%80%E8%87%B4/index.xml" rel="self" type="application/rss+xml"/><item><title>Data Inconsistency</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/data-inconsistency/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/data-inconsistency/</guid><description>&lt;p>資料不一致的核心概念是「同一個業務事實在不同儲存位置呈現不同狀態」。資料庫、快取、搜尋索引、read model、報表、第三方系統與前端本地狀態都可能保存同一個事實的副本，因此更新傳播需要時間與規則。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/data-lifecycle/" data-link-title="Data Lifecycle" data-link-desc="說明資料從建立、使用、保留到刪除的責任邊界">Data Lifecycle&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>資料不一致需要先分辨 source of truth 與衍生資料。Source of truth 承擔正式判斷，例如訂單付款狀態；衍生資料負責查詢、展示或分析，例如搜尋索引與報表。設計時要明確哪些資料可以重建，哪些資料代表正式狀態。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/data-lifecycle/" data-link-title="Data Lifecycle" data-link-desc="說明資料從建立、使用、保留到刪除的責任邊界">Data Lifecycle&lt;/a>。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>系統需要處理資料不一致的訊號是不同入口看到不同結果。使用者頁面、客服後台、管理報表、搜尋頁、通知訊息與第三方系統若對同一筆資料有不同說法，團隊就需要追蹤資料從正式來源到各副本的傳播路徑。&lt;/p>
&lt;h2 id="接近真實網路服務的例子">接近真實網路服務的例子&lt;/h2>
&lt;p>使用者取消訂單後，訂單詳情顯示已取消，但搜尋列表仍顯示可出貨。若出貨流程讀搜尋索引，可能產生錯誤操作；若出貨流程讀正式訂單資料，搜尋列表延遲只影響展示。這個差異決定修復優先級。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>資料不一致的 runbook 要能回答四件事：正式來源在哪裡、哪些副本落後、更新事件是否送達、是否需要補償或重建。系統也要提供版本、更新時間、correlation id 或事件 ID，讓排查能沿著資料流定位。&lt;/p></description><content:encoded><![CDATA[<p>資料不一致的核心概念是「同一個業務事實在不同儲存位置呈現不同狀態」。資料庫、快取、搜尋索引、read model、報表、第三方系統與前端本地狀態都可能保存同一個事實的副本，因此更新傳播需要時間與規則。 可先對照 <a href="/blog/backend/knowledge-cards/data-lifecycle/" data-link-title="Data Lifecycle" data-link-desc="說明資料從建立、使用、保留到刪除的責任邊界">Data Lifecycle</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>資料不一致需要先分辨 source of truth 與衍生資料。Source of truth 承擔正式判斷，例如訂單付款狀態；衍生資料負責查詢、展示或分析，例如搜尋索引與報表。設計時要明確哪些資料可以重建，哪些資料代表正式狀態。 可先對照 <a href="/blog/backend/knowledge-cards/data-lifecycle/" data-link-title="Data Lifecycle" data-link-desc="說明資料從建立、使用、保留到刪除的責任邊界">Data Lifecycle</a>。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>系統需要處理資料不一致的訊號是不同入口看到不同結果。使用者頁面、客服後台、管理報表、搜尋頁、通知訊息與第三方系統若對同一筆資料有不同說法，團隊就需要追蹤資料從正式來源到各副本的傳播路徑。</p>
<h2 id="接近真實網路服務的例子">接近真實網路服務的例子</h2>
<p>使用者取消訂單後，訂單詳情顯示已取消，但搜尋列表仍顯示可出貨。若出貨流程讀搜尋索引，可能產生錯誤操作；若出貨流程讀正式訂單資料，搜尋列表延遲只影響展示。這個差異決定修復優先級。</p>
<h2 id="設計責任">設計責任</h2>
<p>資料不一致的 runbook 要能回答四件事：正式來源在哪裡、哪些副本落後、更新事件是否送達、是否需要補償或重建。系統也要提供版本、更新時間、correlation id 或事件 ID，讓排查能沿著資料流定位。</p>
]]></content:encoded></item></channel></rss>