IOSOR Znalosti
Kdy musí limit embedded tenanta zastavit odesílání
Limity fair-share uvnitř produktu ISV musí natvrdo zastavit odesílání pro daného tenanta — nikdy nevracet falešné API 200 delivered.
V rámci embedded multi-tenant SaaS musí limity fair-share skutečně zastavit provoz, nikoliv jen zobrazit varování v dashboardu. Jakmile tenant narazí na strop, API musí okamžitě vracet explicitní chybu a odmítat další požadavky, aby nedošlo k vyčerpání sdílených prostředků. Falešný návratový kód 200 totiž ničí rekonciliaci dat a zakrývá přetížení. Před spuštěním pilotu jasně definujte jednotky limitu, resetovací okna i chování UI při pozastavení služby.
Dosažení limitu znamená odmítnutí, ne nekonečné varování
Měkká varování slouží pouze jako včasná upozornění. Při dosažení tvrdého stropu vrátí embedded služba chybu o překročení limitu tenanta a nevolá zprávové API pro nové požadavky. Rozpracované zprávy mohou dokončit zpracování; nové požadavky na OTP a kampaně čekají na reset nebo schválené navýšení.
Nikdy nevytvářejte doručený úspěch na omezené cestě
| Odpověď | Kdy je povoleno | Zakázáno při |
|---|---|---|
| Produktový limit / pozastaveno | Dosažen tvrdý strop | Odmítnutí na základě limitu |
| HTTP neúspěch / chyba | Odmítnutí limitu | — |
| Doručeno /. |
Slaďte produktové limity s hranicemi zastavení peněženky
Tenant může být pod svým limitem fair-share, zatímco hranice zastavení peněženky ISV je již červená. V takovém případě se pozastaví celá embedded cesta — nejen hlučný tenant. Zelený stav peněženky však neruší omezení tenanta, který již vyčerpal svůj příděl. Používejte jednotný jazyk stavů: tenant capped vs account paused vs obojí.
Otestujte zastavení ve stagingu s hlučným tenantem
Před produkcí proveďte test ve stagingu: jeden tenant zaplaví systém OTP zprávami, dokud se neaktivuje limit, ostatní tenanti dále odesílají a exporty zobrazují řádky odmítnutí bez falešných doručení. Pokud se ostatní tenanti zastaví, limit je špatně nastaven.
Související provozní cesty
- Vynucování limitů rychlosti napříč multi-tenant účty
- Přetečení fronty: zastavit, tichá ztráta nepřípustná
- hranice zastavení peněženky před produkčním provozem
Začněte s IOSOR
Otevřete konzoli IOSOR a nastavte limity spravedlivého podílu pro podklienty tak, aby brána při dosažení stropu vynutila odmítnutí odeslání. Upravte mapování odpovědí API, aby překročení limitu vracelo explicitní chybový stav namísto akceptovaného datového payloadu. Proveďte test v stagingovém prostředí s vytíženým podklientem a ověřte, že provoz ostatních tenantů plynule pokračuje, zatímco zamítnuté požadavky jsou zaznamenány v protokolech jako jednoznačná odmítnutí.
Shrnutí IOSOR
Měkká varování nedokážou ochránit navazující fronty, když jeden podklient neočekávaně naroste. Tento provozní návod prokázal, že stropy spravedlivého podílu musí fungovat jako okamžité odmítnutí na vstupní bráně a udržovat jasné oddělení mezi překročením limitu tenanta a globálními zastavovacími liniemi rozpočtu.
Pro aplikovanou vrstvu vracíte zřetelné chybové stavy pro překročené limity, aby si podklienti mohli řádně požádat o jejich navýšení. Nevracejte falešná potvrzení 200 ani doručenky pro zamítnuté pokusy, protože vytváření iluze úspěchu zakrývá skutečné selhání doručení a ničí auditovatelnost tenanta.
Byl tento průvodce užitečný?
Související průvodci
- Vstupování API vs. partnerský portál white-label
SaaS produkty, které vkládají zprávy, zůstávají v rozhraní ISV. Partnerské portály white-label patří pod sekci Partner — nemíchejte značku, klíče a vlastníky.
- Odeslání koncovým uživatelem stále čerpá z jedné předplacené hlavní knihy
Integrované odesílání stále debetuje předplacenou peněženku ISV. Nevymýšlejte druhou hlavní knihu, kterou produkt nefinancuje.