Коли cap tenant у вбудованому продукті зобов’язаний зупинити send

Вбудованому 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

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 зламаний.

Пов’язані шляхи

• Rate limits subtenant і fair share
• Overflow черги: stop, не silent drop
• Stop lines wallet до production

Почніть з IOSOR

Налаштуйте жорсткі ліміти для тенантів у консолі IOSOR та перевірте, що сервіс повертає помилку відмови замість хибного HTTP 200. Проведіть тестування у staging-середовищі: запустіть інтенсивний потік від одного суборендаря, щоб спрацював кап, і переконайтеся, що інші тенанти продовжують надсилати трафік без затримок. Перевірте через вебхуки, що статус відхилення чітко розрізняє ліміт тенанта та загальну зупинку балансу.

Підсумок IOSOR

Ліміти справедливого використання (fair-share caps) усередині ISV-продукту повинні фізично блокувати відправку нових повідомлень при досягненні стелі. Повернення підробленого статусу успіху або HTTP 200 на лімітованому шляху руйнує аналітику, приховує проблеми черги та позбавляє клієнтів можливості вчасно підняти тариф або зупинити розсилку.

Робіть чітке розмежування між лімітом конкретного тенанта та загальною зупинкою гаманця ISV, передаючи прозорі статуси відмови через API. Не імітуйте успішну доставку для відхилених запитів і не залишайте м'які попередження без жорсткого механізму зупинки на рівні шлюзу.