लॉन्च के दौरान वेबहुक विफलता रीट्राई और आइडेम्पोटेंसी का परीक्षण

लॉन्च के दौरान वेबहुक विफलता रीट्राई और आइडेम्पोटेंसी का परीक्षण.

पायलट चरण में वेबहुक रेजिलिएंस

IOSOR पर लॉन्च के दौरान, टेनेंट एंडपॉइंट डाउनटाइम वास्तविक समय की सूचनाओं को बाधित कर सकता है। विफलता रीट्राई और आइडेम्पोटेंसी लॉजिक को सत्यापित करने से यह सुनिश्चित होता है कि SMS डिलीवरी रसीद (DLR) और OTP स्थिति परिवर्तन जैसी घटनाएं कभी खोती या दोबारा बिल नहीं होती हैं। जब टेनेंट एंडपॉइंट HTTP 500 या टाइमआउट लौटाते हैं, तो पाइपलाइन पेलोड को बफर करती है और बैकऑफ़ लागू करती है।

परीक्षण के लिए लाइव ट्रैफिक के दौरान रिसीवर विफलताओं का अनुकरण करने की आवश्यकता होती है। परीक्षण URL पर HTTP 503 प्रतिक्रियाएं डालकर, ऑपरेटर यह सत्यापित करते हैं कि संदेश की घटनाएं बिना स्थिति गिराए या लेजर को दूषित किए सुरक्षित रूप से रखी गई हैं।

बैकऑफ़ शेड्यूल और DLR डिलीवरी

जब घटनाएं ट्रिगर होती हैं — जैसे आउटबाउंड SMS स्थिति अपडेट या इनबाउंड STOP कीवर्ड मिलान — तो IOSOR कॉन्फ़िगर किए गए वेबहुक URI पर डिलीवरी का प्रयास करता है। यदि गैर-2xx प्रतिक्रियाएं होती हैं, तो इंजन एक्सपोनेंशियल बैकऑफ़ में बदल जाता है, जो एंडपॉइंट की सुरक्षा के लिए 15 सेकंड से लेकर कई घंटों तक रीट्राई करता है।

आउटेज विंडो के दौरान प्राथमिकता कतारें DLR अपडेट को संभालती हैं। समाप्त रीट्राई घटनाओं को कंसोल में failed-webhook के रूप में चिह्नित करते हैं। परीक्षण साबित करता है कि स्थानीयकृत रिपोर्टिंग वेबहुक डाउनटाइम के दौरान ट्रांजेक्शनल OTP प्रवाह सक्रिय रहते हैं।

आइडेम्पोटेंसी सत्यापन और बैलेंस सुरक्षा

नेटवर्क रीकनेक्ट में सख्त आइडेम्पोटेंसी हेडर के बिना डुप्लीकेट अनुरोधों का जोखिम होता है। डुप्लीकेट शुcharges या दो बार प्रेषण को रोकने के लिए, प्रत्येक API अनुरोध पेलोड में एक अद्वितीय आइडेम्पोटेंसी कुंजी होनी चाहिए।

रीट्राई के दौरान, IOSOR सक्रिय लेजर इंडेक्स के मुकाबले कुंजी की जांच करता है। मिलान करने वाली कुंजियां बिना लेनदेन को फिर से निष्पादित किए कैश्ड प्रतिक्रियाएं लौटाती हैं। परीक्षण सत्यापित करता है कि टेनेंट रीट्राई डुप्लीकेट SMS प्रेषण या अतिरिक्त नंबर आवंटन से बचते हैं।

प्रीपेड लेजर नियंत्रण और सीमाएं

वित्तीय नियंत्रण तत्काल लेजर होल्ड पर निर्भर करते हैं। JIT नंबर आवंटन मासिक शुcharges (MRC) और उपयोग के लिए तत्काल होल्ड रखता है। E.164 नंबर बिना मैनुअल स्टेजिंग के सीधे खातों से जुड़ते हैं।

खातों को USD 20 का प्रीपेड फ्लोर बनाए रखना चाहिए। इस सीमा से नीचे गिरने पर नए आवंटन और आउटबाउंड ट्रैफिक रुक जाते हैं। पायलट परीक्षणों के दौरान रैपिड वॉल्यूम स्पाइक aggregate खर्च में USD 1,000/माह के पास सॉफ्ट समीक्षा को ट्रिगर करते हैं।

डायग्नोस्टिक वर्कफ़्लो और रनबुक

आउटेज सिमुलेशन उत्पादन ट्रैफिक को स्केल करने से पहले रीट्राई पैरामीटर और कतार की गहराई को सत्यापित करते हैं।

लॉन्च प्रबंधन विवरण के लिए इन गाइडों की समीक्षा करें:

• पायलट सप्ताह लॉन्च: पहले लाइव संदेश के बाद की रनवे स्थिति
• लॉन्च इंसिडेंट हफ्ता: लाल स्कोर एक फ्रीज है, मार्केटिंग पुश नहीं
• आइडेम्पोटेंसी, रीट्राई और पैसा

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

IOSOR कंसोल पर जाएं और एंडपॉइंट आउटेज सिमुलेशन निष्पादित करने के लिए वेबहुक डायग्नोस्टिक्स पैनल तक पहुंचें। अपने प्राप्त करने वाले सर्वर पर 503 HTTP प्रतिक्रियाओं को मजबूर करते हुए परीक्षण SMS DLR घटनाओं का एक बैच ट्रिगर करें। पुनः प्रयास के समय को सत्यापित करने के लिए वास्तविक समय में बैकऑफ़ कतार की निगरानी करें और सुनिश्चित करें कि द्वितीयक प्रसंस्करण के बिना डुप्लिकेट आइडमपोटेंसी कुंजियों को फ़िल्टर किया गया है।

IOSOR सार

एंडपॉइंट विफलता का अनुकरण करना यह साबित करता है कि बैकऑफ़ पुनः प्रयास तर्क और आइडमपोटेंसी सत्यापन अप्रत्याशित टेनेंट डाउनटाइम के दौरान परिचालन अखंडता को बनाए रखते हैं। पेलोड डिडुप्लीकेशन को सत्यापित करना यह सुनिश्चित करता है कि डुप्लिकेट इवेंट डिलीवरी कभी भी बिलिंग रिकॉर्ड को विकृत न करे या संदेश स्थिति फ़्लैग को न बदले।

प्रत्येक आउटबाउंड इवेंट पर अद्वितीय आइडमपोटेंसी कुंजियाँ सेट करें और लाइव पायलट भेजने से पहले बैकऑफ़ शेड्यूल का निरीक्षण करें। यह न मानें कि गैर-2xx प्रतिक्रियाएं स्वतः ठीक हो जाएंगी या डुप्लिकेट डिलीवरी रसीदों को आंतरिक स्थिति परिवर्तन को फिर से ट्रिगर करने की अनुमति देंगी।