當授權資料不可信時，我選擇讓系統安靜地退後一步
延續上一篇的問題 在上一篇文章中，我們遇到了一個問題：Link Table 資料遺失導致使用者沒有角色，所有 API 都回傳 401。 文章最後我拋出了一個問題： 如果你的系統把角色資訊 cache 在 Redis、JWT claim、或 BFF 層，當 Link Table 資料不正確時，系統應該： 名詞解釋： Redis：一種高速的記憶體資料庫（In-Memory Database），常用於快取（Cache）熱門資料，避免每次都查詢主資料庫 JWT claim：JWT Token 內的資料欄位。例如把使用者角色直接寫在 Token 裡：{ "sub": "user_123", "role": "admin" }，這樣就不用每次都查 DB BFF（Backend For Frontend）：一種架構模式，在前端和後端 API 之間多一層「專為前端服務的後端」，常會在這層做權限快取 立即全站拒絕？ 繼續相信 cache？ 還是進入 degraded mode？ 我的選擇是：進入 Degraded Mode。 這篇文章會解釋為什麼，以及如何實作。 一句話定義 Degraded Mode = 系統已知自己「部分不可信」，主動降級功能以維持安全與可用性。 不是壞了、不是裝沒事，而是： 我知道哪裡壞 我知道哪些功能不能給 我知道要保住什麼 為什麼不選另外兩個方案？ ❌ 方案 A：立即全站拒絕 所有 API → 401/503 → 業務全掛 問題： 使用者完全無法使用系統 對業務衝擊太大 「寧可錯殺一百」的策略在商業系統中代價過高 適用場景： 金融交易、醫療處方等「錯了比沒有更糟」的場景 ...