題幹與適用情境
這是一題產品判斷題：開發者 API 需要保護共享資源，又不能讓正常整合在不透明的 429 錯誤中失敗。你要決定限制什麼、按誰限制、不同方案如何區分、客戶端如何提前知道邊界，以及如何證明政策改善可靠性而沒有阻斷有價值的使用。
先採用面試假設：API 有免費、專業與企業三層；請求成本差異很大，同時受請求數、並發、輸入大小和下游計算量影響；一次突發不應拖垮共享依賴；政策可以灰度發布並回滾。示例中的 60 RPM、每月 10,000 次或 80% 告警門檻均為待替換示例，不是業界標準。
面試官考察重點
面試官希望看到產品策略與技術限制相互解釋：
- 能否把「限流」「配額」「並發上限」「成本預算」定義成不同產品承諾；
- 是否從開發者完成任務的路徑出發，而不是只按方案收費；
- 能否解釋按組織、專案、API key、使用者或 IP 限制的公平性與濫用風險；
- 是否提供可預測的錯誤、回應標頭、儀表板、告警與申請提升路徑；
- 能否用護欄指標觀察成功率、重試放大、資源成本、留存與客服負擔；
- 是否設計灰度、例外、申訴、回滾與政策變更通知。
普通回答會列出「免費低配、企業高配」；強回答會說明每個限制保護什麼資源、為開發者帶來什麼結果，以及如何驗證副作用。
回答前需要釐清的問題
先問這些會改變政策的限制：
- 保護對象是什麼？ 是閘道 CPU、資料庫連線、模型 token、第三方費用，還是單一租戶的公平份額？不同對象可能需要不同維度。
- 客戶的工作負載是什麼形狀？ 穩定請求、短時突發、批次處理與長連線不能共用一個每分鐘數字。
- 限制是硬上限還是軟預算？ 硬上限保護安全邊界；軟預算允許排隊、降級或額外付費，但必須有明確回饋。
- 計費與限流是否同一維度？ token 消耗、請求次數與並發連線可能分別計量；綁成一個指標會讓客戶難以預測成本。
- 什麼是成功？ 目標是減少依賴過載、提高首次成功呼叫、控制毛利，還是提升高價值開發者留存？排序不同會改變方案設計。
30 秒回答框架
可以這樣開場：
「我先區分四個承諾：短時間速率限制保護瞬時容量，月度配額控制預算，並發上限保護同時占用的資源，成本預算防止不可預測帳單。接著以組織或專案作為主要計量主體，依端點成本設定請求數和資源量兩個維度；方案差異提供更高預算、突發容量、並發和支援回應，而不是只提高一個 RPM。客戶端可從文件、回應標頭和控制台看到剩餘量、重置時間與 Retry-After。我會先灰度到少量租戶，觀察成功率、重試放大、成本、升級和留存，再決定擴大或回滾。」
這段回答明確單位、使用者體驗與驗證閉環，之後再展開演算法或商業細節。
分步深入解答
把限制對象寫成產品契約。 速率限制回答「這一小段時間允許多少請求」；配額回答「計費週期內允許多少資源」；並發限制回答「同時占用多少執行槽位」。分開三者，客戶才能判斷一次 429 是瞬時擁塞、週期預算用完，還是並發耗盡。長任務還需要最大執行時間或排隊預算。
從工作負載而非方案名稱推導單位。 低成本讀取可以按請求計量；昂貴操作應按輸入位元組、輸出 token、計算秒或資料庫掃描量計量。先畫出關鍵客戶任務的請求序列，再決定每個端點的成本單位。不要承諾一個能涵蓋所有端點的「統一 RPM」。
選擇計量主體與公平規則。 組織或專案通常比 IP 更適合付費 API，因為 NAT 會把多個客戶混在一起，單一 API key 又可能透過輪換繞過限制。可以在組織級預算下設定專案級並發，再用 IP 作為異常流量護欄。企業例外必須可稽核，不能讓業務口頭承諾繞過平台規則。
設計方案差異。 免費層應能完成一個小而完整的試用任務；專業層提高週期預算和突發容量，並提供更高並發；企業層增加穩定容量、專屬支援或合規控制。每層都要寫清超限行為：立即拒絕、排隊、降級或按量付費。只提高數字卻不提高可預測性，通常會增加支援負擔。
讓客戶端可預期。 文件、控制台和回應標頭應展示剩餘量、重置時間和請求 ID。伺服器回傳 429 時，客戶端可依 Retry-After 等待；指數退避和最大重試次數防止重試風暴。對不可重試的業務錯誤不要誘導重試。沒有足夠上下文時，回傳穩定錯誤碼和下一步，而不是只寫「Too Many Requests」。
定義上線與護欄指標。 主要指標可包括首次成功呼叫率、合法請求的 429 率、達到 80% 週期預算的客戶比例、單位請求毛利、客服工單、升級轉換和 30 天留存。護欄指標包括重試放大倍數、下游 p99、濫用事件和跨租戶資源爭用。所有指標要按方案、端點和工作負載切分，避免平均數掩蓋某類客戶受損。
灰度、例外與回滾。 先對內部專案和少量客戶以影子模式計算新政策，不改變回應；對比舊策略後再灰度拒絕。給受影響客戶遷移窗口、預算預警和臨時提升流程。若合法請求成功率下降或重試放大超過門檻，回滾策略版本，而不是臨時手工改資料庫。
用可計算假設測試。 假設一個專業專案每分鐘穩定 40 次、短時峰值 120 次，若只給 60 RPM，平穩流量滿足但突發會頻繁 429。可以把速率限制設為 60 RPM、突發容量 120，並把月度預算另算；這只是示例。壓測要涵蓋突發、並發、多個專案共用組織預算、時鐘邊界、重試客戶端和升級後的策略傳播。
高品質示範回答
「我會先把保護對象和開發者承諾分開。速率限制保護短時間容量，週期配額控制預算，並發上限保護同時占用的執行槽位；昂貴端點再按輸入大小或計算量計量。計量主體以組織為主、專案為次，IP 只作濫用護欄，避免 NAT 把正常客戶誤合併。免費層必須完成小型端到端試用，專業層提高週期預算、突發和並發，企業層提供穩定容量、合規控制和可稽核的臨時提升；每層都明確超限是拒絕、排隊、降級還是按量付費。
客戶端在文件、控制台和回應標頭看到剩餘量、重置時間、請求 ID；429 遵守 Retry-After，SDK 使用有上限的指數退避，避免重複請求放大。上線時先影子計算新政策，再對少量專案灰度。主要指標是首次成功呼叫率、合法請求 429 率、單位請求成本和升級轉換，護欄是重試放大、下游 p99、工單和 30 天留存。如果合法請求失敗率超過預設門檻，我會回滾策略版本並延長遷移窗口，而不是臨時給單一客戶開不可稽核的後門。」
這個答案的關鍵是把產品單位、使用者可預測性、技術行為和實驗決策連起來。數字應換成真實業務基準，不能把示例配額當成預設答案。
常見錯誤
- 只說「免費低配、企業高配」。 沒有說明保護對象與超限行為。為每個限制綁定資源、客戶任務與回饋。
- 把 RPM 當作全部成本。 大請求和長任務可能消耗更多下游資源；增加資源量或並發維度。
- 按 IP 作為唯一客戶身份。 NAT、代理和 key 輪換會破壞公平與可稽核性；以組織或專案為主，IP 作護欄。
- 讓客戶端盲目重試。 429 後立即重試會放大擁塞；遵守
Retry-After，使用指數退避和最大次數。 - 只看收入或 429 率。 高收入可能伴隨成功率下降，低 429 可能表示系統過度預留；同時觀察體驗、成本和可靠性。
- 用業務特批取代政策。 臨時後門難以撤銷且破壞公平；使用有期限、可稽核、可回滾的提升流程。
追問與應對
客戶說突發流量導致 429，但月度配額還剩很多，怎麼辦？
說明週期配額與瞬時速率是不同承諾。檢查端點成本和客戶任務，把合理突發納入方案或申請臨時突發容量；同時在回應標頭、文件與控制台說明重置與等待方式。不要直接把所有客戶的 RPM 無限提高。
如果一個大客戶要求不受限流影響，你會答應嗎？
先要求工作負載、依賴成本和可靠性目標。可以提供預留容量、專屬佇列或有期限的上限提升，但仍保留系統級安全護欄，並記錄審批、價格、過期時間和回滾條件。無限承諾會把風險轉移給其他客戶與下游服務。
429 率下降但客戶留存也下降，如何判斷政策是否失敗？
按端點、方案、工作負載與遷移階段切片，檢查是否透過更寬上限掩蓋成本或延遲問題，再結合首次成功呼叫率、工單、預算預警和流失訪談。若只是少數關鍵任務受損，優先修正單位、文件或突發策略，而不是撤銷全部護欄。
客戶跨多個專案共用預算，如何避免一個專案耗盡組織額度？
建立組織總預算與專案級並發／預留的兩層模型；高風險或昂貴端點可要求專案預留。控制台展示組織與專案雙重剩餘量，超出專案額度時明確是專案限制還是組織限制，讓管理員調整預算或優先級。