IOSOR

IOSOR ज्ञान

जब एक एम्बेडेड टैनेंट कैप को भेजने से रोकना चाहिए

ISV प्रोडक्ट के भीतर फेयर-शेयर कैप को उस टैनेंट के लिए भेजने की प्रक्रिया को पूरी तरह से रोकना चाहिए — कैप हिट होने पर कभी भी फर्जी डिलीवर किया गया API 200 न लौटाएं।

एम्बेडेड मल्टी-टैनेंट SaaS को फेयर-शेयर कैप की आवश्यकता होती है ताकि कोई एक अत्यधिक सक्रिय टैनेंट साझा प्रीपेड बैलेंस को समाप्त न कर दे या अन्य टैनेंट्स को प्रभावित न करे। एक कैप जो API द्वारा सबमिट स्वीकार करने के दौरान केवल डैशबोर्ड चेतावनी दिखाता है, वह बेकार है। जब टैनेंट सीमा तक पहुंच जाता है, तो उस टैनेंट के लिए भेजने की प्रक्रिया को एक स्पष्ट त्रुटि और गैर-सफलता API स्थिति के साथ रोक दिया जाना चाहिए। फर्जी 200 प्रतिक्रियाएं समाधान को नुकसान पहुंचाती हैं और दुरुपयोग को बढ़ावा देती हैं।

कैप्स ISV प्रोडक्ट स्तर में रहते हैं — यह पार्टनर सब-टैनेंट दर सीमाओं का विकल्प नहीं हैं और न ही शांत कतार ड्रॉप्स हैं। एक ईमानदार रोक का अर्थ है: SaaS UI रोक या कैप दिखाता है, एम्बेडेड सेवा उस टैनेंट आईडी के लिए नए सबमिशन को अस्वीकार करती है, और ऑप्स निर्यात कर सकते हैं कि किसने सीमा पार की।

पायलट ट्रैफ़िक से पहले रोक अनुबंध लिखें: कैप यूनिट (संदेश / खर्च / दिन), रीसेट विंडो, कौन बढ़ा सकता है, और अंतिम उपयोगकर्ता क्या देखता है।

सीमा पूरी होने पर सबमिट अस्वीकार करें, हमेशा के लिए चेतावनी न दें

सॉफ्ट चेतावनियाँ केवल शुरुआती अलर्ट हैं। कठोर सीमा पर, एम्बेडेड सेवा टैनेंट-कैप्ड त्रुटि लौटाती है और नए अनुरोधों के लिए मैसेजिंग API को कॉल नहीं करती है। पहले से पाइपलाइन में मौजूद संदेश पूरे हो सकते हैं; नए OTP और अभियान सबमिशन रीसेट या स्वीकृत वृद्धि की प्रतीक्षा करते हैं।

टैनेंट आईडी, कैप नियम और टाइमस्टैम्प के.

कैप किए गए पाथ पर कभी भी डिलीवरी सफलता न दिखाएं

प्रतिक्रिया कब अनुमति है कब निषिद्ध है
प्रोडक्ट कैप्ड / रुका हुआ कठोर सीमा पूरी हो गई कैप अस्वीकार पाथ
HTTP गैर-सफलता / मैप्ड त्रुटि कैप अस्वीकार —
डिलीवर किया गया / 200 सफलता वास्तविक स्वीकार पाथ कैप अस्वीकार
मूक ड्रॉप कभी नहीं हमेशा
मूक ड्रॉप और फर्जी 200 कतार ओवरफ़्लो से मेल खाते हैं जो सफलता का नाटक करते हैं।

प्रोडक्ट सीमाओं को वॉलेट रोक लाइनों के साथ संरेखित करें

एक टैनेंट अपनी फेयर-शेयर कैप के तहत हो सकता है जबकि ISV वॉलेट रोक लाइन पहले से ही लाल हो सकती है। तब पूरा एम्बेडेड पाथ रुक जाता है — न केवल वह सक्रिय टैनेंट। वॉलेट का चालू होना उस टैनेंट को छूट नहीं देता जिसने पहले ही अपना हिस्सा समाप्त कर दिया है। एक ही स्थिति भाषा साझा करें: टैनेंट कैप्ड बनाम खाता रुका हुआ।

वृद्धि अनुरोधों के लिए एक नामित अनुमोदक.

एक शोर वाले टैनेंट के साथ स्टेगिंग में रोक का परीक्षण करें

प्रोडक्शन से पहले, स्टेगिंग ड्रिल चलाएं: एक टैनेंट तब तक OTP भेजता है जब तक कि कैप ट्रिप न हो जाए, अन्य टैनेंट भेजते रहते हैं, और एक्सपोर्ट बिना फर्जी डिलीवरी के अस्वीकार पंक्तियों को दिखाता है। यदि अन्य टैनेंट रुक जाते हैं, तो कैप का दायरा गलत है।

संबंधित संचालन पथ

IOSOR के साथ शुरुआत करें

IOSOR कंसोल खोलें और सबटेनेंट फेयर-शेयर सीमाएं सेट करें ताकि कैप तक पहुंचने पर सबमिट गेट पर सख्त अस्वीकृति लागू हो सके। अपने एपीआई रिस्पॉन्स मैपिंग को कॉन्फ़िगर करें ताकि कैप किए गए टेनेंट्स को स्वीकृत पेलोड के बजाय एक स्पष्ट स्टेटस त्रुटि प्राप्त हो। यह सुनिश्चित करने के लिए एक शोरगुल वाले टेनेंट के साथ स्टेजिंग टेस्ट चलाएं कि कैप किए गए सबमिट्स को स्पष्ट अस्वीकृति लॉग प्रविष्टियों के रूप में दर्ज किया जाए, जबकि बाकी ट्रैफ़िक स्वतंत्र रूप से प्रवाहित हो।

IOSOR सार

जब कोई एक सबटेनेंट अचानक बढ़ता है, तो सॉफ्ट चेतावनियाँ डाउनस्ट्रीम कतारों की रक्षा करने में विफल हो जाती हैं। इस परिचालन गाइड ने साबित कर दिया कि फेयर-शेयर कैप को तत्काल सबमिट गेट अस्वीकृति के रूप में कार्य करना चाहिए, जिससे टेनेंट कैप हिट और वैश्विक वॉलेट स्टॉप लाइन्स के बीच स्पष्ट अलगाव बना रहे।

अपने एप्लिकेशन लेयर को अलग-अलग कैप किए गए स्टेटस रिस्पॉन्स अवश्य दें ताकि टेनेंट्स उचित रूप से सीमा बढ़ाने का अनुरोध कर सकें। कैप किए गए प्रयासों के लिए नकली 200 स्वीकृति या डिलीवर किए गए डीएलआर वापस न करें, क्योंकि झूठी सफलता दिखाने से वास्तविक डिलीवरी विफलताएं छिप जाती हैं और टेनेंट की ऑडिटेबिलिटी खराब हो जाती है।

क्या यह गाइड मददगार थी?

संबंधित गाइड