題目與範圍
本題考察 API 協定邊界設計。參考文件是 2026 年 5 月 23 日發布的 Internet-Draft，尚不是 RFC；回答先說明此狀態。部署可能只採用部分欄位，因此契約要能安全降級。
面試官考察什麼
- 清楚區分配額策略中繼資料與目前可用配額。
- 結構化欄位解析、多時間視窗、配額單位與分區鍵。
- 與 429、Retry-After、閘道、CDN 及快取陳舊值的關係。
- 暴露限額造成的隱私與拒絕服務風險。
- 客戶端把提示視為非綁定資訊，能處理缺失或畸形欄位並退避。
建議答題結構
先定義配額維度與責任歸屬。展示包含策略與目前限額的回應，再解釋客戶端如何排隊。補充快取與中介層規則、安全約束、觀測指標，以及帶功能開關的漸進發布，讓草案變化不破壞客戶端。
深入拆解：提供有用提示但不承諾容量
分離策略與目前狀態
RateLimit-Policy 描述命名配額，例如 "tenant";q=1000;w=60。RateLimit 回報目前可用配額與有效視窗，例如 "tenant";r=420;t=23。策略可含多個項目與可變視窗。服務端仍是最終權威；這些值是提示，不是租約或服務等級保證。
定義分區與單位語義
說明一個配額單位代表請求、位元組、Token 或加權操作。分區鍵可區分租戶或資源，但不要把電郵、原始使用者 ID 或密鑰放入標頭。策略名稱應穩定並帶版本；不改名稱卻改變單位會讓客戶端節流失效。
協調 429 與 Retry-After
服務端知道拒絕請求何時可再次嘗試時回傳 Retry-After。兩者同時出現時，客戶端優先遵守 Retry-After；RateLimit 用於安排後續工作。草案沒有規定具體節流演算法，所以客戶端仍需封頂指數退避、抖動、截止時間與寫入操作冪等規則。
讓快取和中介層參與契約
快取回應的 RateLimit 可能陳舊，回應具有正的 current age 時應忽略。不了解配額語義的中介層不能讓回應看起來更寬鬆。強制更嚴格限額的閘道可以傳達更嚴格策略，同時在遙測中區分源站與閘道決定。
保護可用性與隱私
不要暴露會洩露流量規模或放大攻擊的超大視窗。限制可用配額與視窗的比值，校驗結構化欄位並忽略畸形值。容量緊張時可以降低廣告值，但客戶端仍須處理拒絕，因為上一次提示健康不代表本次一定成功。
範例回答
「我會按租戶與操作定義帶版本的命名策略，明確單位，並把策略中繼資料與目前剩餘配額分開。該文件仍是 Internet-Draft，因此客戶端把兩類欄位都當作可選提示。被拒絕的請求由 Retry-After 指導，RateLimit 安排後續速度。CDN 讓陳舊值失效，閘道不會把源站限額放寬，分區鍵不含身分資訊。SDK 防禦性解析結構化欄位，使用抖動與共享佇列；先按 SDK 版本灰度並記錄宣稱限額與實際執行限額。」
常見失誤與修正
- 把草案稱為 RFC → 記錄 Internet-Draft 狀態，並用版本化契約隔離。
- 把剩餘配額當作許可 → 它只是提示；容量緊張時服務端仍可拒絕。
- 在分區鍵放使用者識別 → 使用不透明、低基數名稱並評估隱私暴露。
- 信任快取標頭 → 忽略陳舊值，由源站執行限額。
- 每次 429 立即重試 → 遵守
Retry-After，加入抖動並按方法定義冪等性。
評分標準與自檢
評分點包括策略/狀態分離、單位與分區、429 互動、快取行為、隱私、客戶端節流、灰度安全與指標。高品質回答應說明每個欄位的含義、不能保證什麼，以及欄位缺失、陳舊或畸形時客戶端如何行動。
追問與延伸
回應含有兩個視窗怎麼辦？
按最先耗盡的約束安排速度，同時保留全部項目用於觀測。SDK 不應把單位或分區鍵不同的視窗悄悄合併。
成功回應應包含 RateLimit 嗎？
可以，但客戶端不能假定每個回應都有。只有在產品確實需要時傳送，並確保快取不會把舊值變成目前承諾。
如何發布變化中的草案？
協商回應標頭設定或策略版本，記錄解析降級，按 SDK 版本灰度；新欄位保持可選，同時穩定 429 與 Retry-After 行為。
哪些指標證明契約有效？
按閘道與 SDK 版本記錄宣稱與執行限額、陳舊值決策、429 率、重試放大、佇列延遲、最終成功率及隱私安全的分區基數。