IOSOR

IOSOR Kunnskap

Når et innebygd tenant-tak må stoppe utsending

Fair-share-tak i et ISV-produkt må stoppe utsending for den tenanten — aldri returnere en falsk levert API 200 når taket er nådd.

Innebygd multi-tenant SaaS trenger fair-share-tak slik at én støyende tenant ikke brenner opp den felles forhåndsbetalte hovedboken eller sulter ut andre tenanter. Et tak som bare viser en advarsel i et dashbord mens API-et fortsatt godtar innsendinger, er teater. Når tenanten når sin grense, må utsending for den tenanten stoppe med en eksplisitt produktfeil og en tilknyttet API-status for manglende suksess. Falske leverte 200-svar ødelegger avstemming og oppfordrer til misbruk.

Tak plasseres i ISV-produktlaget — ikke som en erstatning for Partner-underkontoers hastighetsgrenser, og ikke som stille drop i køen. Ærlig stopp: SaaS UI viser pauset eller nådd tak, embed-tjenesten avviser nye innsendinger for den tenant-ID-en, og driftsteamet kan eksportere hvem som nådde taket.

Skriv stoppkontrakten før pilottrafikk: enhet for tak (meldinger / forbruk / dag), tilbakestillingsvindu, hvem som kan øke taket, og hva sluttbrukeren ser.

Nådd tak betyr avvist innsending, ikke uendelige advarsler

Myke advarsler er bare tidlige varsler. Ved det harde taket returnerer embed-tjenesten en feil om nådd tenant-tak og kaller ikke meldings-API-et for nye intensjoner. Meldinger underveis som allerede er behandlet kan fullføres; nye OTP- og kampanjeinnsendinger venter på tilbakestilling eller en godkjent økning.

Opprett aldri levert suksess på en begrenset sti

Respons Når tillatt Forbudt ved
Produkt tak / pauset Hardt tak nådd Sti for avvist tak
HTTP ikke-suksess / feil Avvisning av tak —
Levert / 200 suksess Reell aksept og hold-sti Avvisning av tak
Stille drop Aldri Alltid

Stille drop og falske 200-svar tilsvarer køoverløp som later.

Samkjør produkttak med wallet-stoppgrenser

En tenant kan ligge under sitt eget fair-share-tak mens ISV-wallet-stoppgrensen allerede er rød. Da settes hele embed-stien på pause — ikke bare den støyende tenanten. En grønn wallet opphever ikke begrensing for en tenant som allerede har brukt opp sin andel. Bruk et felles statusspråk: tenant-tak nådd kontra konto pauset eller begge deler.

Test stoppet i staging med en støyende tenant

Før produksjon må det kjøres en staging-test: én tenant oversvømmer systemet med OTP til taket utløses, andre tenanter fortsetter å sende, og eksporter viser avvisningsrader uten falske leveringsbekreftelser. Hvis andre tenanter stopper opp, er taket feil plassert. Hvis den støyende tenanten fortsatt ser grønne haker, er stoppet defekt.

Relaterte driftsbaner

Start med IOSOR

Åpne IOSOR-konsollet og sett rettferdig delingsgrense for underleietakere slik at innsendingsporten gir harde avvisninger når taket er nådd. Konfigurer API-responsflyten slik at treff på taket gir en eksplisitt feilstatus i stedet for et akseptert resultat. Kjør en test i testmiljøet med en krevende leietaker for å sikre at øvrig trafikk flyter fritt, samtidig som avviste innsendinger logges som klare avvisninger.

IOSOR-lærdom

Myke advarsler verner ikke nedstrøms køer når en enkelt underleietaker sender store mengder. Denne driftsveiledningen viser at grenser for rettferdig deling må fungere som en umiddelbar avvisning ved innsendingsporten, slik det holdes et tydelig skille mellom leietakertak og globale stanslinjer.

Send alltid egne statusresponser for taktreff til applikasjonslaget slik at leietakere kan be om utvidede grenser på riktig måte. Ikke send falske 200-bekreftelser eller leveringsrapporter for avviste forsøk, da fiktive suksessmeldinger skjuler faktiske feil og ødelegger sporingen for leietakeren.

Var denne guiden nyttig?

Relaterte veiledninger