嵌入式租戶上限何時必須停止發送

嵌入式多租戶 SaaS 需要公平分享上限(fair-share caps)，這樣單一高流量租戶就不會耗盡共享的預付帳戶餘額或影響其他租戶的正常使用。如果上限設定僅在儀表板上顯示警告，而 API 仍然繼續接收提交，這只是表面功夫。當租戶達到限制時，該租戶的發送必須立即停止，並返回明確的產品錯誤與映射的非成功 API 狀態。虛假的已送達 200 回應會破壞數據對帳並引發系統濫用。

上限設定存在於 ISV 產品層級——這不能替代 Partner 子租戶的速率限制，也不是佇列中的靜默丟棄。真實的停止意味著：SaaS UI 顯示已暫停或已達上限，嵌入式服務拒絕該租戶 ID 的新提交，維運團隊可以匯出觸及上限的紀錄。

在正式試行流量前撰寫停止合約：上限單位(訊息數 / 支出 / 天)、重置週期、誰有權提升上限，以及最終使用者看到的提示。

觸及上限代表拒絕提交，而非永久軟性警告

軟性警告僅用於早期提醒。在達到硬性上限時，嵌入式服務會返回租戶上限錯誤，且不會為新請求呼叫訊息 API。已經在處理中的訊息可以完成；新的 OTP 與行銷活動提交則需等待重置或經批准的額度提升。

記錄拒絕日誌，包含租戶 ID、上限規則與時間戳記。當客戶聲稱發送功能故障時，技術支援團隊需要該筆紀錄進行排查。

絕不在已達上限的路徑上製造送達成功的假象

靜默丟棄與虛假 200 回應如同假裝成功的佇列溢位。架構擴充處理的是溢位停止；而這裡的觸發條件是 ISV 內部的租戶公平分享規則。

將產品上限與錢包停損線保持一致

租戶可能尚未達到其公平分享上限，但 ISV 錢包停損線已經亮起紅燈。此時整個嵌入式路徑都會暫停——而不僅僅是高流量租戶。錢包狀態正常並不能豁免已經耗盡自身配額的租戶。統一狀態語言：租戶已達上限 vs 帳戶已暫停 vs 兩者皆是。

提額申請需要指定的審核人。自服務式的無限制提額會破壞公平分享機制。

在 Staging 環境中使用高流量租戶測試停止機制

在進入正式環境前，於 Staging 環境進行演練：讓單一租戶發送大量 OTP 直到觸發上限，其他租戶保持正常發送，匯出紀錄顯示拒絕明細且無虛假送達。如果其他租戶也陷入停頓，說明上限作用域設定錯誤。如果高流量租戶依然看到綠色勾勾，代表停止機制失效。

相關維運路徑

• 安全地跨多租戶帳戶執行速率限制
• 佇列溢位：停止，絕不靜默丟棄
• 正式流量前的錢包停損線

從 IOSOR 開始

請開啟 IOSOR 主控台，並設定子租戶公平分攤上限，以便在達到容量時於送出閘道強制拒絕。請設定您的 API 回應對應，讓達到上限的租戶收到明確的狀態錯誤，而非已被接受的資料負載。請使用高流量租戶在測試環境進行測試，以確保其他租戶的流量能順暢通行，同時將受限制的送出記錄為明確的拒絕日誌條目。 Cap 命中必須拒絕 submit，禁止偽造成功 delivered；stop 要在 staging 用吵鬧 tenant 驗過。

IOSOR 要點

當單一子租戶流量激增時，柔性警告無法保護下游佇列。本操作指南證明，公平分攤上限必須作為即時的送出閘道拒絕機制，以維持租戶上限觸發與全域錢包停用線之間的清晰區隔。

請務必將明確的上限狀態回應傳回至您的應用程式層，以便子租戶能適當申請提高限制。請勿針對受限制的嘗試傳回虛假的 200 接受狀態或已送達的 DLR，因為捏造成功會掩蓋真正的傳遞失敗並破壞租戶的可稽核性。