IOSOR

IOSOR Viden

Når et indlejret tenant-loft skal stoppe afsendelse

Fair-share-lofter i et ISV-produkt skal stoppe afsendelsen for den tenant — aldrig returnere en falsk leveret API 200, når loftet er nået.

Indlejret multi-tenant SaaS har brug for fair-share-lofter, så én støjende tenant ikke opbruger den fælles forudbetalte hovedbog eller udsulter andre tenanter. Et loft, der kun viser en advarsel i et dashboard, mens API'et stadig accepterer indsendelser, er et teater. Når tenanten når sin grænse, skal afsendelsen stoppes med en eksplicit produktfejl og en tilknyttet API-status for manglende succes. Falske leverede 200-svar ødelægger afstemningen og opfordrer til misbrug.

Lofter placeres i ISV-produktlaget — ikke som en erstatning for Partner-underkontoers hastighedsgrænser og ikke som stille drop i køen. Ærligt stop: SaaS UI viser pauset eller nået loft, embed-tjenesten afviser nye indsendelser for det tenant-ID, og driftsteamet kan eksportere data om, hvem der ramte loftet.

Skriv stopkontrakten før pilottrafik: enhed for loft (beskeder / forbrug / dag), nulstillingsvindue, hvem der må hæve loftet, og hvad slutbrugeren ser i grænsefladen.

Nået loft betyder afvisning af anmodning, ikke uendelige advarsler

Bløde advarsler er kun tidlige varsler. Ved det faste loft returnerer embed-tjenesten en fejl om nået tenant-loft og kalder ikke besked-API'et for nye intentioner. Beskeder undervejs, der allerede er behandlet, kan gennemføres; nye OTP- og kampagneindsendelser venter på nulstilling eller en godkendt forhøjelse.

Opret aldrig leveret succes på en begrænset sti

Svar Hvornår tilladt Forbudt ved
Produkt loft / pauset Fast loft nået Sti for afvisning af loft
HTTP ikke-succes / fejl Afvisning af loft —
Leveret / 200 succes Reel accept og hold-sti Afvisning af loft
Stille drop Aldrig Altid

Stille drop og falske 200-svar svarer til køoverløb, der lad.

Tilpas produktlofter til wallet-stopgrænser

En tenant kan ligge under sit eget fair-share-loft, mens ISV-wallet-stopgrænsen allerede er rød. I så fald sættes hele embed-stien på pause — ikke kun den støjende tenant. En grøn status på wallet ophever ikke begrænsningen for en tenant, der allerede har opbrugt sin andel.

Test stoppet i staging med en støjende tenant

Før produktion skal der kores en staging-test: én tenant oversvømmer systemet med OTP, indtil loftet udløses, øvrige tenanter fortsætter afsendelsen, og eksporter viser afvisningsrækker uden falske leveringsbekræftelser. Hvis øvrige tenanter blokerer, er loftet placeret forkert. Hvis den støjende tenant stadig ser grønne flueben, er stoppet defekt.

Relaterede driftsstier

Start med IOSOR

Åbn IOSOR-konsollen, og indstil dine underlejerens fair-share-grænser for at gennemtvinge afvisninger ved indsendelsesporten, når lofterne nås. Konfigurer din API-svarkortlægning, så begrænsede lejer modtager en eksplicit statusfejl i stedet for en accepteret nyttelast. Kør en test i staging-miljøet med en støjende lejer for at sikre, at den øvrige trafik flyder frit, mens afviste indsendelser registreres som eksplicitte afvisningslogfiler.

IOSOR-pointe

Bløde advarsler beskytter ikke nedstrøms køer, når en enkelt underlejer oplever en stigning. Denne driftsvejledning beviste, at fair-share-lofter skal fungere som en øjeblikkelig afvisning ved indsendelsesporten, hvilket opretholder klar adskillelse mellem lejerens loftsmatch og de globale stoplinjer for tegnebøger.

Returner tydelige svarkoder for loftsmatch til dit applikationslag, så underlejer kan anmode om forhøjede grænser på passende vis. Returner ikke falske 200-acceptsvar eller leverede DLR-rapporter for afviste forsøg, da det at udstede falsk succes slører reelle leveringsfejl og ødelægger lejerens reviderbarhed.

Var denne guide nyttig?

Relaterede vejledninger