題幹與適用場景
配額服務回答「現在能不能占用這部分資源」，但不負責搬運檔案或執行業務操作。題目考察你能否把額度的權威狀態、暫時預留與最終使用分開，並在共享基礎設施上保持公平。
面試官考察什麼
- 能否區分速率限制、容量配額、預留與提交。
- 能否設計不會超賣的並發更新與冪等 API。
- 能否處理預留過期、呼叫方崩潰、重試與對帳修復。
- 能否解釋多租戶公平、熱點、跨區域一致性與降級策略。
回答前需要釐清的問題
先確認資源維度（請求次數、位元組、並發工作）、配額範圍（租戶、專案、使用者或端點）、是否有突發額度與層級配額；預留需持續多久；消費是強一致計費還是允許暫時超額；以及跨區域請求能否路由到單一權威區域。
30 秒回答架構
我會把服務建成按資源鍵維護 limit、committed、reserved 的權威狀態機，提供 reserve、commit、release 與查詢介面。預留用條件更新原子檢查剩餘額度，帶冪等 reservation_id 與到期時間；提交把預留轉成實際使用，釋放或逾時則歸還。事件帳本與定期對帳修復漂移，路由與租戶公平策略避免單一熱點拖垮其他租戶。
分步驟深入解答
1. 定義狀態與 API 邊界
配額紀錄包含資源鍵、上限、已提交量、預留量、版本與更新時間。reserve 回傳 reservation_id、可用量與到期時間；commit 只能消費自己的預留；release 可重複呼叫；查詢回傳剩餘額度與更新時間。業務服務在真正寫入資源前預留，成功後提交，失敗或取消時釋放。
2. 保證並發下不超賣
單一資源鍵的變更必須在同一原子交易或線性化儲存操作中完成：只有 committed + reserved + amount <= limit 才能增加預留。冪等鍵重複請求回傳原結果，參數不一致則拒絕。高並發熱點可按租戶或資源分片，但要說清是否允許暫時超額及如何合併。
3. 回收洩漏的預留
呼叫方可能在預留後崩潰，因此記錄到期時間並由掃描器或延遲佇列回收。回收與提交競爭時用狀態條件：已提交不能再釋放，已釋放不能再次提交。回收延遲應納入指標，避免把未及時清理誤認為可用額度。
4. 處理共享池與租戶公平
共享池可同時受全域、租戶與專案層級約束，檢查順序要固定並在一次交易中完成。突發流量按租戶配額、優先級或加權公平分配，不能讓單一租戶耗盡共享池。把剩餘額度、重試時間或排隊狀態回傳客戶端，減少盲目重試。
5. 故障、跨區域與對帳
權威儲存不可用時，寧可短暫拒絕高風險預留，也不要在未知狀態放行計費資源；低風險讀取可回傳帶時間戳的近似值。跨區域可按租戶固定主區域，或採帶邊界的本地配額並非同步對帳。每次預留、提交、釋放寫入不可變帳本，定期與實際使用對帳，漂移用冪等補償任務修復。
高品質示範回答
我會先釐清資源、租戶層級、預留時間與一致性要求。服務維護每個資源鍵的 limit、committed、reserved 與版本，提供帶 reservation_id 的 reserve、commit、release 與查詢 API。reserve 在原子條件更新中檢查三者總和，重複請求回傳同一結果；呼叫方寫入成功後 commit，失敗或取消 release，過期由回收任務處理。共享池同時檢查全域與租戶額度，以固定路由、優先級或加權策略維持公平。權威儲存故障時對高風險寫入保守拒絕，跨區域按租戶固定主區域或設定本地超額邊界。所有狀態變更寫入帳本，與實際使用定期對帳。
常見錯誤
- 把配額服務等同於只回傳 429 的速率限制器。
- 先讀剩餘量再寫入，沒有原子條件導致並發超賣。
- 沒有 reservation_id、到期時間與冪等語意。
- 預留者崩潰後額度永久占用。
- 只談租戶限額，忽略共享池、層級約束與公平性。
追問及應對
呼叫方在 commit 前逾時，應重試還是重新 reserve？
先用相同 reservation_id 查詢或重試 commit，確保冪等；確認預留已釋放或過期後才建立新預留。
一個租戶多個產品共用額度怎麼辦？
以租戶作共享父級、產品作子級約束，在同一交易檢查兩層；失敗時說明是哪一層耗盡，方便降級或排隊。
可以跨區域同時預留嗎？
計費資源不能超賣時用單一權威區域或強一致協調。允許有限超額時，為每區設定借額上限，並把超額與償還納入對帳。
如何發現額度與實際使用不一致？
用帳本事件、資源掃描與週期對帳比較 committed、reserved 與真實使用，依租戶和資源類型告警；補償任務要冪等並保留稽核紀錄。