[005] 【減法】歷史軌跡有什麼不好？我們為何選擇讓資料消失而不是保留
作為一個車隊防走失工具，即時位置是核心。開發初期，團隊內也曾熱烈討論：「要不要把所有隊員的行進軌跡都保存下來？這樣領隊回頭能重播，分析路線或追蹤走失隊員不是很好嗎？」乍聽之下，這個功能似乎對用戶「很有用」。然而，在資源有限與隱私至上的前提下，我們最終做出了「不保存歷史軌跡，讓位置資料自動消失」的艱難減法。
我們的核心問題點在於：如果保存完整的歷史軌跡，它將變成一份可被追溯、可被調取的「監控數據」。這與我們設計 FollowMe8 的初衷——一個輕量、無負擔、用完即丟的協作工具——產生了嚴重衝突。一個強調「防走失」的工具，不應該成為用戶隱私的潛在風險。其次，單人開發與維運的資源極為有限，處理海量的軌跡資料將帶來巨大的儲存成本與效能負擔。
我們考慮過兩種方案：
選項一 (被放棄)： 設計資料庫 schema 以儲存完整的歷史軌跡。這意味著 `activity_locations` 表會不斷累積每個隊員、每個時間點的座標。雖然可以透過定期批次刪除或歸檔來管理，但實作與維護成本高昂，且難以從根本上解決「監控」的潛在疑慮。
選項二 (我們選擇的方案)： 只保存每個隊員的「最後已知位置」，並設定短暫的生命週期。當隊員停止更新位置超過一定時間，資料即自動失效。
我們最終選擇了選項二，主要基於以下幾點考量：
1. 隱私保護與信任： 我們堅信「軌跡資料 = 可被調取的監控數據」，這違背了 FollowMe8「用完即丟」的設計原則。透過 Redis 的 TTL (Time-To-Live) 機制，`loc:{activity_id}:{member_id}` 這個鍵值對的生命週期被嚴格限制在 `2 分鐘`。只要超過 2 分鐘沒有更新，系統便會將其視為離線，且該位置資料會自動從 Redis 快取中刪除。用戶能夠清楚認知到，他們的位置資訊是即時分享、目的達成後即消失，不會被永久記錄或儲存。
2. 資源與成本最佳化： 單一開發者沒有無限的儲存空間和運算資源。放棄儲存歷史軌跡，大幅簡化了後端資料庫設計。我們的 `activity_locations` 表只保存每個活動中成員的最後一筆位置 (`activity_id FK + member_id FK + 座標 + recorded_at`)，並且透過 `idx_activity_time (activity_id, recorded_at)` 索引快速查找，明確不支援軌跡重播。這不僅節省了昂貴的資料庫儲存成本，也減少了未來因資料量增長而需進行複雜資料歸檔、分區或清理的工作量。
這個決策對用戶的實際影響是深遠的：用戶將得到一個極度重視隱私的防走失工具。他們無需擔心自己的活動足跡會被無限期地保存、分析或被第三方濫用。這種「資料用完即丟」的保證，大大提升了用戶對 App 的信任感與使用意願。同時，精簡的資料模型也確保了 App 和後端系統的輕量與高效，直接體現了「精簡架構、省電無感、直覺易用」的核心目標，確保使用者不跟丟且無後顧之憂。如果我們選擇了保存軌跡，用戶將面臨隱私疑慮，系統也將背負不必要的資源壓力。
—
👉 了解更多關於 FollowMe8 短期活動追蹤定位 App：
https://followme8.ofuyuan.com/