0.2 狀態與資料儲存選型

2026-04-23

狀態與資料儲存選型的核心原則是先判斷資料責任。正式狀態、暫存資料、搜尋索引、事件歷史與大型檔案都屬於資料，但它們需要不同服務能力。

本章目標

學完本章後，你將能夠：

資料儲存服務的第一個問題是「這份資料扮演什麼責任」。同一份商品資料可以同時出現在 PostgreSQL、Redis、Elasticsearch、event log 與 object storage 裡，但每個位置的責任不同。

這張表是索引。選型時要看資料是否能重建、是否需要一致性、是否要被使用者查詢、是否承擔稽核責任。

Source of truth 的核心責任是保存系統承認的正式狀態。當資料需要被交易保護、被多個流程共同讀寫、支援一致查詢與長期保存時，應先評估資料庫。

接近真實網路服務的例子包括：

這類資料的主要風險是寫入一致性。服務要知道誰能改狀態、哪些欄位要一起成功、失敗後如何重試或補償。這些問題通常屬於資料庫與 transaction 邊界。

cache 的核心責任是降低讀取成本。快取資料應該能從 source of truth 或下游服務重建；它的價值在於吸收熱門讀取、降低延遲、保護正式資料來源。

接近真實網路服務的例子包括：

這類資料的主要風險是過期與不一致。服務要知道 cache miss 怎麼處理、TTL 如何設定、資料更新時如何失效、熱門 key 如何保護。

Search index 的核心責任是支援搜尋體驗。當使用者需要全文搜尋、排序、filter、facet、autocomplete 或相關性排序，搜尋索引通常比一般資料庫查詢更合適。

接近真實網路服務的例子包括：

這類資料的主要風險是索引延遲與查詢語意。正式狀態通常仍在資料庫，search index 是為搜尋體驗建立的讀取模型。服務要知道資料更新後多久進索引、搜尋結果是否允許短暫延遲。

Event log 的核心責任是保存已發生的事。當系統需要 audit、replay、補送、狀態重建或跨服務事件傳遞，事件歷史就需要獨立設計。

接近真實網路服務的例子包括：

這類資料的主要風險是順序、重複與 schema 演進。Event log 要說明事件代表哪個 domain fact、如何去重、如何處理舊版本 payload。

Object storage 的核心責任是保存大型 blob。當資料是圖片、影片、PDF、匯出報表、備份檔或模型檔案，儲存服務通常需要 object storage，而正式 metadata 放在資料庫。

接近真實網路服務的例子包括：

這類資料的主要風險是存取權限、生命週期、版本與連結有效性。資料庫保存 object key、owner、狀態與 metadata；object storage 保存實際檔案內容。

當以下問題都能回答時，代表本章的概念層已完成，可以進入資料儲存實作章節：

下一步建議路由：

資料儲存選型要先問資料責任。正式狀態進資料庫，可重建讀取資料進快取，搜尋體驗用 search index，歷史與重播用 event log，大型檔案用 object storage。責任分清楚後，同一份業務資料可以出現在多個服務中，但每個服務的位置都能被解釋。