IOSOR జ్ఞానం
ఎంబెడెడ్ టెనెంట్ క్యాప్ పంపడాన్ని ఎప్పుడు నిలిపివేయాలి
ISV ఉత్పత్తిలోని ఫెయిర్-షేర్ క్యాప్లు ఆ టెనెంట్ కోసం పంపడాన్ని ఖచ్చితంగా నిలిపివేయాలి — క్యాప్ తాకినప్పుడు నకిలీ డెలివరీ చేయబడిన API 200ను ఎప్పుడూ తిరిగి ఇవ్వకూడదు.
ఎంబెడెడ్ మల్టీ-టెనెంట్ SaaS సిస్టమ్లో ఒకే టెనెంట్ అధిక ట్రాఫిక్తో ఇతరుల ప్రీపెయిడ్ బ్యాలెన్స్ను ఖాళీ చేయకుండా ఉండటానికి ఫెయిర్-షేర్ క్యాప్లు అత్యంత అవసరం. టెనెంట్ తమ పరిమితిని చేరుకున్నప్పుడు, స్పష్టమైన ప్రొడక్ట్ ఎర్రర్ మరియు విఫలమైన API స్టేటస్తో మెసేజ్ల పంపడాన్ని వెంటనే నిలిపివేయాలి. డ్యాష్బోర్డ్లో కేవలం హెచ్చరికలు చూపిస్తూ, నకిలీ 200 ఓకే రెస్పాన్స్ ఇస్తే ledger సరిపోలిక దెబ్బతింటుంది. కాబట్టి ప్రొడక్షన్ ప్రారంభానికి ముందే క్యాప్ యూనిట్, రీసెట్ విండో మరియు నిలిపివేత నిబంధనలను స్పష్టంగా నిర్వచించాలి.
క్యాప్ చేరడం అంటే సమర్పణను తిరస్కరించడం, శాశ్వత మృదువైన హెచ్చరిక కాదు
మృదువైన హెచ్చరికలు ప్రారంభ హెచ్చరికలు మాత్రమే. పరిమితికి చేరినప్పుడు, ఎంబెడెడ్ సేవ టెనెంట్-క్యాప్డ్ లోపాన్ని తిరిగిస్తుంది మరియు కొత్త అభ్యర్థనల కోసం మెసేజింగ్ APIని పిలవదు. ఇప్పటికే ప్రాసెస్ అవుతున్న సందేశాలు పూర్తి కావచ్చు; కొత్త OTP మరియు ప్రచార సమర్పణలు రీసెట్ లేదా అనుమతించబడిన పెంపు కోసం వేచి ఉంటాయి. టెనెంట్ ID, క్యాప్ నియమం మరియు టైమ్స్టాంప్తో తిరస్కరణను లాగ్ చేయండి.
క్యాప్ చేసిన మార్గంలో ఎప్పుడూ విజయవంతమైన డెలివరీని చూపవద్దు
| ప్రతిస్పందన | ఎప్పుడు అనుమతించబడుతుంది | ఎప్పుడు నిషేధించబడుతుంది |
|---|---|---|
| ఉత్పత్తి పరిమితం / నిలిపివేయబడింది | పరిమితికి చేరినప్పుడు | క్యాప్ తిరస్కరణ మార్గం |
| HTTP వైఫల్యం / లోపం | క్యాప్ తిరస్కరణ | — |
| డెలివరీ చేయబడింది. |
వాలెట్ నిలుపు పరిమితులతో ఉత్పత్తి క్యాప్లను సమలేఖనం చేయండి
ISV వాలెట్ నిలుపు పరిమితి ఎరుపు రంగులోకి మారినప్పుడు టెనెంట్ తన ఫెయిర్-షేర్ పరిమితి కంటే తక్కువగా ఉండవచ్చు. అప్పుడు మొత్తం ఎంబెడ్ మార్గం నిలిపివేయబడుతుంది — అధిక ట్రాఫిక్ ఉన్న టెనెంట్ మాత్రమే కాదు. వాలెట్ ఆకుపచ్చగా ఉండటం ఇప్పటికే పరిమితిని దాటిన టెనెంట్కు మినహాయింపు ఇవ్వదు. పెంపు అభ్యర్థనలకు ఒక నిర్దిష్ట ఆమోదకర్త అవసరం.
ఎక్కువ ట్రాఫిక్ ఉన్న టెనెంట్తో స్టేజింగ్లో నిలిపివేతను పరీక్షించండి
ప్రొడక్షన్కు ముందు, స్టేజింగ్లో రన్ చేయండి: ఒక టెనెంట్ క్యాప్ ట్రిప్ అయ్యే వరకు OTPలను పంపుతుంది, ఇతర టెనెంట్లు పంపడం కొనసాగిస్తాయి మరియు ఎగుమతులు నకిలీ డెలివరీలు లేకుండా తిరస్కరణ వరుసలను చూపిస్తాయి. ఇతర టెనెంట్లు ఆగిపోతే, క్యాప్ స్కోప్ తప్పుగా ఉంది.
సంబంధిత ఆపరేషన్స్ మార్గాలు
- మల్టీ-టెనెంట్ ఖాతాలలో రేట్ పరిమితులను సురక్షితంగా అమలు చేయడం
- క్యూ ఓవర్ఫ్లో: ఆపు, సైలెంట్-డ్రాప్ చేయవద్దు
- ప్రొడక్షన్ ట్రాఫిక్కు ముందు వాలెట్ నిలుపు పరిమితులు
IOSOR తో ప్రారంభించండి
IOSOR కన్సోల్ తెరిచి, పరిమితులు దాటినప్పుడు సబ్మిట్ గేట్ వద్దే కఠినమైన తిరస్కరణలను అమలు చేయడానికి మీ సబ్-టెనెంట్ ఫెయిర్-షేర్ పరిమితులను సెట్ చేయండి. పరిమితికి చేరిన టెనెంట్లు అంగీకరించిన పేలోడ్కు బదులుగా స్పష్టమైన స్టేటస్ లోపాన్ని పొందేలా మీ API రెస్పాన్స్ మ్యాపింగ్ను కాన్ఫిగర్ చేయండి. పరిమితిలో ఉన్న సమర్పణలు స్పష్టమైన తిరస్కరణ లాగ్ ఎంట్రీలుగా రికార్డ్ చేయబడుతున్నప్పుడు, ఇతర ట్రాఫిక్ సజావుగా సాగేలా చూడటానికి ఒక నాయిసీ టెనెంట్తో స్టేజింగ్ పరీక్షను అమలు చేయండి.
IOSOR సారాంశం
ఒక టెనెంట్ ట్రాఫిక్ ఒక్కసారిగా పెరిగినప్పుడు కేవలం సాఫ్ట్ హెచ్చరికలు డౌన్స్ట్రీమ్ క్యూలను రక్షించలేవు. టెనెంట్ క్యాప్ హిట్లకు మరియు గ్లోబల్ వాలెట్ స్టాప్ లైన్లకు మధ్య స్పష్టమైన విభజనను कायम ఉంచుతూ, ఫెయిర్-షేర్ క్యాప్లు తక్షణ సబ్మిట్ గేట్ తిరస్కరణ వలె పనిచేయాలని ఈ ఆపరేషనల్ గైడ్ నిరూపించింది.
సబ్టెనెంట్లు తగిన విధంగా పరిమితి పెంపును అభ్యర్థించడానికి మీ అప్లికేషన్ లేయర్కు విభిన్నమైన క్యాప్డ్ స్టేటస్ ప్రతిస్పందనలను తిరిగి ఇవ్వండి. క్యాప్డ్ ప్రయత్నాల కోసం నకిలీ 200 అంగీకారం లేదా డెలివర్ అయిన DLRలను తిరిగి ఇవ్వవద్దు, ఎందుకంటే తప్పుడు విజయాలను చూపడం నిజమైన డెలివరీ వైఫల్యాలను దాచిపెడుతుంది మరియు టెనెంట్ ఆడిటబిలిటీని పాడుచేస్తుంది.
ఈ గైడ్ సహాయకరంగా ఉందా?
సంబంధిత గైడ్లు
- API ఎంబెడ్డింగ్ వర్సెస్ వైట్-లేబుల్ పార్టనర్ పోర్టల్
మెసేజింగ్ను ఎంబెడ్ చేసే SaaS ఉత్పత్తులు ISV ఉపరితలంపైనే ఉంటాయి. వైట్-లేబుల్ పార్టనర్ పోర్టల్లు భాగస్వామి కింద ఉంటాయి — బ్రాండ్ మరియు కీలను మిశ్రమం చేయవద్దు.
- అంతిమ వినియోగదారు పంపే మెసేజ్ కూడా ఒకే ప్రీపెయిడ్ లెడ్జర్ను డెబిట్ చేస్తుంది
ఎంబెడెడ్ సెండ్ ఇంకా ISV ప్రీపెయిడ్ వాలెట్ నుంచే డెబిట్ అవుతుంది. ఉత్పత్తి ఫండ్ చేయని రెండవ లెడ్జర్ను సృష్టించవద్దు — హోల్డ్లు, రీట్రైలు మరియు ఐడెంపొటెన్సీ నిజాయితీగా ఉండాలి.