ADR-0003：物件儲存只做暫存，不當永久素材庫

狀態

已採用

背景

上傳的影片與圖片要放在哪裡？最常見的答案是「放在物件儲存裡，永遠留著」。

決策

RustFS 只做暫存與派送：

• 原始檔在轉檔成功後立即刪除。
• 縮圖與預覽長期保留（它們很小）。
• 播放產物在所有目標裝置都 ACK 且經過保留期後回收。
• 正式的播放副本最終保存在裝置本機。

當某個素材已經沒有任何可派送的副本時，把它標記為 NEEDS_REUPLOAD 並在介面上誠實顯示。

理由

原始檔在系統裡沒有讀者。 一支 4K 原始影片可能有 8 GB，轉檔後的播放版本只有 200 MB。播放用轉檔版、預覽用預覽版、縮圖用縮圖——沒有任何功能會去讀那 8 GB 的原始檔。留著它只是讓儲存成本隨上傳量線性成長。

播放副本已經在裝置上了。 素材的用途就是被裝置播放。所有目標裝置都下載完成並驗證通過之後，RustFS 上那份副本就沒有讀者了。

這是一個產品定位的決定。 HUAN 是播放系統，不是數位資產管理系統。想要保存原始母帶的人應該用 DAM，而不是期待看板系統替他做備份。

後果

這個決定有一個真實的、使用者會遇到的代價：

原始檔已刪除、播放產物也已回收之後，如果你新增一台裝置，或某台裝置清掉了本機儲存，這份素材就無法重新派送，必須重新上傳。

我們選擇正面處理這件事：

• 資料模型本身能表達這個狀態（media_variants.available）。
• 後台會明確顯示「需要重新上傳」，並解釋原因。
• 文件在多個地方說明這個限制。
• 保留期可以透過 DISTRIBUTION_RETENTION_HOURS 調整，設成 720 就等於一個月內都能重新派送。

不會做的事：假裝伺服器還留著不存在的檔案，然後在派送的時候才失敗。

回收前的兩道保護也很重要：必須所有目標裝置都 ACK（不能第一台成功就刪），而且必須經過保留期（吸收 ACK 與重試之間的競態）。

替代方案

永久保留原始檔：儲存成本無上限地成長，而且那些檔案沒有讀者。

永久保留播放產物：比保留原始檔便宜得多，也確實避免了重新上傳的問題。這是最值得未來重新評估的選項——只要把 DISTRIBUTION_RETENTION_HOURS 設得夠大，實務上就等於這個方案。目前的預設值選擇了成本，而不是便利。