IOSOR

IOSOR База знаний

Когда cap tenant во встроенном продукте обязан остановить send

Fair-share caps внутри продукта ISV обязаны hard-stop send для tenant — никогда не отдавайте fake delivered API 200 при ударе в потолок.

Встроенному multi-tenant SaaS нужны fair-share caps, чтобы один шумный tenant не сжёг общий prepaid ledger и не задушил соседей. Cap, который только красит warning, пока API принимает submit, — театр. При ударе в лимит send этого tenant останавливается с явной product-ошибкой и mapped non-success статусом API. Fake delivered 200 убивает reconciliation и учит abuse.

Caps живут в product layer ISV. Они не заменяют Partner subtenant rate limits и не равны silent queue drop. Честный stop: UI показывает paused или capped, embed-сервис отказывает новым submit для tenant id, ops экспортирует, кто ударил в потолок.

Stop-контракт до pilot: единица cap, окно reset, кто raise, что видит end user. Добавьте owner на refuse-код в embed-сервисе и канал эскалации, если raise нужен вне окна reset.

Удар в cap значит отказать submit, а не soft-warn вечно

Soft warning — только early alert. На hard ceiling embed возвращает tenant-capped ошибку и не вызывает messaging API для новых intent. In-flight с hold могут завершиться; новые OTP и campaign ждут reset или approved raise.

Логируйте отказ: tenant id, правило cap, timestamp. Support нужен ряд, когда клиент кричит, что Send сломан.

Никогда не чеканьте delivered success на capped path

Ответ Когда можно Запрещено когда
Product capped / paused Hard ceiling Путь cap refuse
HTTP non-success / mapped error Cap refuse —
Delivered / 200 success Реальный accept + hold Cap refuse
Silent drop Никогда Всегда

Silent drop и fake 200 — тот же класс лжи, что overflow с притворством success. Scale adjacency — overflow stop; здесь триггер — fair-share tenant внутри ISV.

Выровняйте product caps со stop lines wallet

Tenant может быть под cap, пока stop line wallet уже красная — тогда паузится весь embed path. Wallet green не снимает tenant, сжёгший долю. Один язык статуса: tenant capped vs account paused vs оба.

Raise требует именного approver. Unlimited self-serve raise убивает fair share.

Протестируйте stop в staging на шумном tenant

Staging drill: один tenant заливает OTP до cap, siblings шлют, export — refuse без delivered fake. Если siblings встают — scope кривой. Если шумный tenant видит green — stop сломан.

Связанные пути

Начните с IOSOR

Настройте в консоли IOSOR жесткий лимит отправки для тенантов и проверьте обработку ответов через шлюз. Убедитесь, что при превышении квоты сервис возвращает явный статус ошибки tenant-capped, а не формирует ложные webhook-уведомления о доставке. Проведите тестовый прогон в staging-среде, чтобы подтвердить изолированную блокировку лимитированного субклиента без влияния на соседние аккаунты.

Итог IOSOR

Жесткий лимит мультиарендной системы защищает шлюз от исчерпания ресурсов одним шумным субклиентом. Если тенант исчерпал свой лимит, платформа должна немедленно отклонять новые запросы на отправку, сохраняя работоспособность параллельных потоков и общий баланс системы.

Делайте прозрачную обработку превышения лимитов с явными HTTP-ошибками и точной записью отказов в журнале аудита. Не имитируйте успешную доставку со статусом 200 OK при исчерпании квоты и не допускайте сбоев у соседних тенантов при блокировке нарушителя.

Был ли материал полезен?

Связанные гайды