Kun upotetun vuokralaisen raja vaatii lähetyksen pysäyttämisen

Upotettu multi-tenant SaaS tarvitsee fair-share-rajat, jotta yksi äänekäs vuokralainen ei kuluta yhteistä ennakkomaksettua kirjanpitoa tai näännytä muita vuokralaisia. Raja, joka vain näyttää varoituksen hallintapaneelissa mutta sallii API-pyynnöt, on pelkkää teatteria. Kun vuokralainen saavuttaa rajan, lähetyksen on pysähdyttävä selkeään tuotevirheeseen ja vastaavaan API-virhetilaan. Valheelliset delivered 200 -vastaukset tuhoavat täsmäytyksen ja lisäävät väärinkäyttöä.

Rajat sijaitsevat ISV-tuotekerroksessa — ne eivät korvaa Partner-alitilien nopeusrajoituksia eivätkä ole hiljaisia jonon pudotuksia. Rehellinen pysäytys: SaaS UI näyttää tilaksi keskeytetty tai raja saavutettu, upotepalvelu hylkää uudet pyynnöt kyseiselle tenant-ID:lle, ja ylläpito voi viedä raportin rajan saavuttaneista.

Kirjoita pysäytyssopimus ennen pilottiliikennettä: rajayksikkö (viestit / kulutus / päivä), nollausikkuna, korotusoikeudet ja mitä loppukäyttäjälle näytetään.

Rajan saavuttaminen tarkoittaa hylkäystä, ei ikuisia pehmeitä varoituksia

Pehmeät varoitukset ovat vain varhaisia hälytyksiä. Kovalla rajalla upotepalvelu palauttaa tenant-capped-virheen eikä kutsu viesti-API:a uusille pyynnöille. Jo käsitellyt matkalla olevat viestit voivat valmistua; uudet OTP- ja kampanjalähetykset odottavat nollausta tai hyväksyttyä korotusta. Kirjaa hylkäys tenant-ID:n, rajasäännön ja aikaleiman kanssa.

Älä koskaan luo delivered-menestystä rajoitetulla polulla

Hiljainen pudotus ja valheellinen 200 va.

Sovita tuoterajat lompakon pysäytysrajoihin

Vuokralainen voi olla oman fair-share-rajansa alapuolella, vaikka ISV-lompakon pysäytysraja on jo punaisella. Tällöin koko upotepolku pysähtyy — ei vain äänekäs vuokralainen. Lompakon vihreä tila ei vapauta vuokralaista, joka on jo kuluttanut osuutensa. Käytä yhtenäistä tilakieltä: tenant capped vs account paused vs molemmat. Nostopyynnöt vaativat nimetyn hyväksyjän.

Testaa pysäytystä staging-ympäristössä äänekkäällä vuokralaisella

Ennen tuotantoa suorita testiharjoitus staging-ympäristössä: yksi vuokralainen lähettää OTP-viestejä kunnes raja täyttyy, muut vuokralaiset jatkavat lähettämistä, ja raportit näyttävät hylkäysrivit ilman valheellisia delivered-merkintöjä. Jos muiden vuokralaisten lähetys pysähtyy, raja on määritelty väärin.

Liittyvät toimintapolut

• Nopeusrajoitusten valvonta usean vuokralaisen tileillä
• Jonon ylivuoto: pysäytä, älä pudota hiljaisesti
• lompakon pysäytysrajat ennen tuotantoliikennettä

Aloita IOSORilla

Avaa IOSOR-konsoli ja määritä alivuokralaisen reilun jaon rajat niin, että lähetysportti estää ylitykset suoraan. Määritä rajapinnan vastauskartoitus siten, että rajoitettu vuokralainen saa virhekoodin hyväksytyn sisällön sijaan. Tee testaus häiriöherkällä vuokralaisella varmistaaksesi, että muu liikenne kulkee vapaasti ja rajoitukset kirjautuvat selkeinä estomerkintöinä.

IOSOR-yhteenveto

Pehmeät varoitukset eivät suojaa alavirran jonoja, kun yksittäinen alivuokralainen ruuhkauttaa järjestelmän. Tämä opas osoittaa, että reilun jaon rajojen on estettävä lähetykset heti portilla ja erotettava vuokralaiskohtaiset rajat globaaleista pysäytyksistä.

Palauta sovelluskerrokselle erilliset virhekoodit rajoituksista, jotta vuokralaiset voivat pyytää rajojensa nostoa asianmukaisesti. Älä palauta vääriä onnistumisvastauksia rajoitetuille yrityksille, sillä katteeton kuittaus peittää todelliset toimitusongelmat ja tuhoaa kirjanpidon luotettavuuden.