Kapag ang limitasyon ng embedded tenant ay kailangang magpatigil ng pagpapadala

Ang bawat embedded multi-tenant SaaS ay dapat magpatupad ng fair-share caps upang hindi maubos ng isang maingay na tenant ang shared balance ng lahat. Kapag naabot na ang limitasyon, kailangang huminto nang tuluyan ang pagpapadala gamit ang malinaw na error code at non-success API status sa halip na magkunwaring tinanggap ang request. Ang tapat na paghinto sa serbisyo ay nagpoprotekta sa integridad ng data at tinitiyak na ang ISV product layer ay may kontrol sa tamang paggamit ng resources.

Ang pag-abot sa cap ay nangangahulugan ng pagtanggi sa submission, hindi magpakailanman na soft warning

Ang mga soft warning ay maagang alerto lamang. Sa hard ceiling, ang embed service ay nagbabalik ng tenant-capped error at hindi tumatawag sa messaging API para sa mga bagong submission.

Huwag kailanman magpakita ng matagumpay na paghahatid sa naka-cap na daan

I-align ang mga cap ng produkto sa mga linya ng paghinto ng wallet

Ang isang tenant ay maaaring nasa ilalim pa ng fair-share cap nito habang ang linya ng paghinto ng ISV wallet ay nasa pula na. Pagkatapos ay titigil ang buong embed path — hindi lamang ang maingay na tenant. Ang berdeng wallet ay hindi nagpapatawad sa tenant na naubos na ang sariling bahagi.

Subukan ang paghinto sa staging gamit ang maingay na tenant

Bago mag-production, magpatakbo ng subok sa staging: ang isang tenant ay magpapadala ng maraming OTP hanggang sa tumalbog ang cap, ang ibang mga tenant ay patuloy na magpapadala, at ang mga export ay magpapakita ng mga refuse row nang walang pekeng delivered status. Kung ang ibang mga tenant ay huminto din, mali ang sakop ng cap.

Mga kaugnay na ops path

• Ligtas na pagpapatupad ng mga limitasyon sa rate sa mga multi-tenant account
• Overflow ng Queue: huminto, huwag mag-silent drop
• mga hangganan ng wallet bago ang production traffic

Magsimula sa IOSOR

Buksan ang console ng IOSOR at itakda ang iyong mga limitasyon sa patas na hatian ng subtenant upang ipatupad ang mahigpit na pagtanggi sa pintuan ng pagpasa kapag naabot na ang mga hangganan. I-configure ang pagruruta ng tugon ng iyong API upang ang mga nakalinyang subtenant ay makatanggap ng malinaw na error sa status sa halip na tinanggap na kargada. Magpatakbo ng pagsubok sa staging kasama ang isang maingay na subtenant upang matiyak na ang trapiko ng iba ay malayang dumadaloy habang ang mga tinanggihang pagpasa ay naitala bilang mga malinaw na entry sa log ng pagtanggi.

Buod ng IOSOR

Ang mga mahihinang babala ay nabigong protektahan ang mga susunod na pila kapag ang isang nag-iisang subtenant ay lumobo. Pinatunayan ng patnubay sa operasyon na ito na ang mga hangganan ng patas na hatian ay dapat kumilos bilang agarang pagtanggi sa pintuan ng pagpasa, na nagpapanatili ng malinaw na paghihiwalay sa pagitan ng mga pag-abot sa hangganan ng subtenant at ng mga pandaigdigang linya ng paghinto ng pitaka. Huwag magbalik ng magkakaibang mga tugon ng status na may hangganan sa iyong layer ng aplikasyon upang ang mga subtenant ay makahiling ng pagtaas ng limitasyon nang naaangkop. Huwag magbalik ng pekeng pagtanggap na 200 o naihatid na DLR para sa mga tinangkang may hangganan, dahil ang paggawa ng huwad na tagumpay ay nagtatago sa totoong kabiguan sa paghahatid at sumisira sa kakayahang mag-audit ng subtenant.