重點整理
- 減少回傳資料不等於降低系統成本，必須優化底層查詢邏輯。
- 限制敏感資料存取能有效防範個資外洩，同時滿足使用者真實需求。
- 系統設計應從使用者的真實目的出發，只提供最必要的資訊。
- 網站效能與資安息息相關，上線前後都應定期檢視與優化。
你可能不是寫程式的工程師，但你的公司一定有網站、APP 或內部系統。GitHub 最近分享了一個他們優化「星號歷史」API（應用程式介面，也就是系統與系統溝通的橋樑）的真實案例。這個故事不僅解決了系統跑太慢的問題，還順便保護了使用者個資。這背後的產品設計思維，正是企業在規劃或升級自家網站與系統時，最該學習的避坑指南。
為什麼「給得少」不等於「跑得快」？
過去，開發者想查看一個專案的熱度變化，必須透過 API 抓取所有按星者的名單與時間。但這對資料庫（用來儲存所有資料的大倉庫）來說是個惡夢。
因為資料量太大，系統必須把資料分頁（把大量資料分成一頁一頁顯示），但每次分頁時，資料庫還是得把成千上萬筆資料全部掃過一次，才能算出總頁數。這導致即使每次只回傳 100 筆資料，系統效能依然極差。對於擁有 25 萬顆星號的熱門專案，抓取完整歷史需要發出 2,500 多次請求，不僅容易超時，還拖垮了整個資料庫。
這給企業的啟示是：表面上減少回傳的資料量，並不代表系統處理成本變低。如果底層邏輯沒有改變，系統依然會越跑越慢。
保護個資與滿足需求的完美平衡
除了效能問題，舊設計還引發了資安危機。因為 API 會回傳按星者的身份資訊，被有心人士利用來抓取名單，進行垃圾郵件或釣魚攻擊。
GitHub 的解法是：限制只有專案管理員才能看完整名單，直接切斷個資外洩的風險。但這讓原本依賴舊 API 製作熱度圖表的工具失效了。
經過與使用者溝通，GitHub 發現大家真正需要的是「熱度趨勢曲線」，而不是「誰按了星」。於是他們重新設計了 API，不再回傳個人身份，而是直接回傳「每日星號數量」。
更聰明的是，新系統改為「先按時間範圍過濾，再計算數量」。每次請求最多回傳 30 週的每日數據。同樣是 25 萬星號的專案，請求次數從 2,500 次大幅降到 24 次，資料庫也不用再重複掃描所有資料。
給企業的 3 個系統設計啟示
- 從使用者的真實目的出發：舊系統給了一堆身分資訊，但使用者只想要趨勢圖。企業在規劃網站或內部系統時，也要先搞清楚客戶或員工真正想完成的任務，而不是盲目塞入一堆功能。
- 只給必要的資料：任何多餘的資訊都可能成為資安漏洞。系統介接或資料輸出時，遵循最小權限原則，只回傳用例需要的資料。
- 優化底層邏輯，而非只看表面：當系統變慢時，不要只想著限制顯示數量，而是要檢查資料庫的查詢順序，從源頭降低運算負擔。
崴米的建議
從 GitHub 的優化案例可以看出，系統的效能與資安往往是連動的，且需要從一開始就設計好。對於中小企業主來說，當你的網站或系統開始出現讀取緩慢、或是擔心個資外洩風險時，可以參考以下兩點建議：
1. 定期檢視網站效能與基本設定：不要等到客人抱怨網頁跑太慢才處理。建議先使用我們的免費網站健檢服務，快速找出手機版顯示、載入速度與搜尋引擎設定的潛在問題。
2. 適時進行系統架構調整：如果舊網站的後台改不動、速度優化遇到瓶頸，或是需要重新梳理資料流向，可以考慮交由專業團隊評估。我們的網站改版與搬家服務，能幫你接手舊系統，重新打造跑得更快、更安全的數位基礎。
參考來源：From 2,500 requests to 24: Rebuilding star history without the stargazers
