IOSOR Vedomosti
Keď limit embedded tenanta musí zastaviť odosielanie
Limity fair-share vo vnútri produktu ISV musia natvrdo zastaviť odosielanie pre daného tenanta — nikdy nevracať falošné API 200 delivered.
Embedded multi-tenant SaaS vyžaduje prísne limity fair-share, aby jeden hlučný tenant nespotreboval zdieľaný kredit ani nevytlačil ostatných. Ak tenant dosiahne stanovený strop, odosielanie sa musí okamžite zastaviť s jasnou produktovou chybou a zodpovedajúcim neúspešným stavom API. Falošné doručenie so stavom 200 ničí zúčtovanie a podporuje zneužívanie systému. Pravidlá zastavenia, jednotky limitu a okno reštartu preto nastavte ešte pred spustením pilotnej prevádzky.
Dosiahnutie limitu znamená odmietnutie, nie nekonečné varovania
Mäkké varovania slúžia len ako včasné upozornenia. Pri dosiahnutí tvrdého stropu vráti embedded služba chybu o prekročení limitu tenanta a nevolá správové API pre nové požiadavky. Rozpracované správy môžu dokončiť spracovanie; nové požiadavky na OTP a kampane čakajú na reset alebo schválené navýšenie.
Nikdy nevytvárajte doručený úspech na obmedzenej ceste
| Odpoveď | Kedy je povolené | Zakázané pri |
|---|---|---|
| Produktový limit / pozastavené | Dosiahnutý tvrdý strop | Odmietnutie na základe limitu |
| HTTP neúspech /chyba | Odmietnutie limitu | — |
| Doručené / 200 úspech | . |
Zlaďte produktové limity s hranicami zastavenia peňaženky
Tenant môže byť pod svojím limitom fair-share, zatiaľ čo hranica zastavenia peňaženky ISV je už červená. V takom prípade sa pozastaví celá embedded cesta — nie len hlučný tenant. Zelený stav peňaženky však neruší obmedzenie tenanta, ktorý už vyčerpal svoj prídel. Používajte jednotný jazyk stavov: tenant capped vs account paused vs oboje.
Otestujte zastavenie vo stagingu s hlučným tenantom
Pred produkciou vykonajte test vo stagingu: jeden tenant zaplaví systém OTP správami, kým sa neaktivuje limit, ostatní tenanti ďalej odosielajú a exporty zobrazujú riadky odmietnutia bez falošných doručení. Ak sa ostatní tenanti zastavia, limit je nesprávne nastavený.
Súvisiace prevádzkové cesty
- Vynucovanie limitov rýchlosti pre multi-tenant účty
- Pretečenie frontu: zastavenie, žiadne tiché zahadzovanie
- hranice zastavenia peňaženky pred produkčnou prevádzkou
Začnite s IOSOR
Otvorte konzolu IOSOR a nastavte limity spravodlivého podielu pre subklientov tak, aby sa pri dosiahnutí stropu vynútili tvrdé odmietnutia priamo na bráne odoslania. Konfigurujte mapovanie odpovedí API tak, aby obmedzení klienti dostali výslovnú chybovú štruktúru namiesto prijatého dátového balíka. Spustite test v staging prostredí s vyťaženým klientom, aby ste overili, že susedná prevádzka prúdi bez obmedzení, zatiaľ čo blokované podania sa zaznamenávajú ako jasné záznamy o odmietnutí.
Zhrnutie IOSOR
Mäkké varovania nedokážu ochrániť následné fronty, keď jeden subklient zaznamená prudký nárast. Tento prevádzkový sprievodca preukázal, že stropy spravodlivého podielu musia fungovať ako okamžité odmietnutie na bráne podania, čím sa zachováva zreteľné oddelenie medzi zásahmi do limitov klienta a globálnymi zastavovacími čiarami peňaženky.
Vracajte do aplikačnej vrstvy zreteľné stavové odpovede o obmedzení, aby mohli subklienti adekvátne požiadať o zvýšenie limitov. Nevracajte falošné akceptácie 200 ani doručené potvrdenia pre obmedzené pokusy, pretože vytváranie falošného úspechu zakrýva skutočné zlyhania doručenia a ničí auditovateľnosť klienta.
Pomohol tento sprievodca?
Súvisiace návody
- Vstávanie API vs. partnerský portál white-label
SaaS produkty, ktoré vkladajú správy, zostávajú v rozhraní ISV. Partnerské portály white-label patria pod sekciu Partner — nemiešajte značku, kľúče a vlastníctvo.
- Odoslanie koncovým používateľom stále čerpá z jednej predplatenej hlavnej knihy
Integrované odosielanie stále debetuje predplatenú peňaženku ISV. Nevymýšľajte druhú hlavnú knihu, ktorú produkt nefinancuje.