इनबाउंड SMS वेबहुक: रिट्राय, इव्हेंट क्रम आणि प्राप्त करताना आइडेम्पोटेन्सी

आउटबाउंड SMS डॅशबोर्ड घेतो. इनबाउंड हे ठिकाण आहे जिथे STOP, HELP आणि ग्राहक उत्तरे खरोखर उतरतात — आणि जिथे भोले हॅंडलर डुप्लिकेट तिकीटे, दुहेरी वॉलेट साइड-इफेक्ट आणि “आम्हाला STOP कधीच मिळाला नाही” हे compliance भुत बनवतात. तुमचा रिसीव्ह पाथ exactly-once आणि क्रमाने गृहीत धरत असेल तर पहिल्या खऱ्या आउटेजवर तुम्ही कोसळाल.

IOSOR इनबाउंड मेसेजिंगला आउटबाउंडसारख्याच व्हाइट-लेबल प्रीपेड पृष्ठभागात पॅक करतो: पडताळता येणारे इव्हेंट, ब्रँड-सुरक्षित पेलोड, उत्तर वादळ जुळवण्यासाठी परदेशी ops पोर्टलमध्ये न राहता.

वेबहुक पुन्हा प्रयत्न का करतात

बहुतेक प्लॅटफॉर्मवर इनबाउंड वेबहुक रिट्रायसह at-least-once डिलिव्हरी वचन देतात, जादुई exactly-once कडक क्रम नाही.

• त्याच लॉजिकल इव्हेंटचे डुप्लिकेट POST
• टाइमआउट नंतर उशीरा आगमन
• दुसऱ्या इव्हेंट प्रकाराच्या तुलनेत कधीकधी out-of-order

उत्पादन UX तरीही क्रमाने वाटू शकते जर तुमचा स्टोअर निर्धारक मर्ज लागू करेल — जर तार कधीही थरथरणार नाही अशी आशा असेल तर नाही.

तीन अपयश मोड ज्यासाठी डिझाइन आवश्यक

आइडेम्पोटेन्सी: एक गुण जे तिन्ही दुरुस्त करतो

इव्हेंट क्रम: “last write wins” धोकादायक का

सामान्य चुकीची गृहीते:

1. STOP पुढच्या मार्केटिंग सेंडपूर्वी येईल (रेस आहे)
2. आउटबाउंड DLR इनबाउंड रिप्लायपूर्वी येईल (स्वतंत्र मार्ग)
3. टिकाऊ इव्हेंट कीशिवाय “पहिले POST जिंकते”

टिकाऊ event / message id ने रिसीव्ह लेजर बांधा. व्यवसाय नियम त्या लेजरवरील स्टेट ट्रान्झिशन; “प्रत्येक HTTP 200 मार्गावर साइड इफेक्ट” नाही.

1. इनबाउंड कॉलबॅकसाठी नोंदवलेली रिट्राय धोरण
2. चाचणीयोग्य स्वाक्षरी / auth पडताळणी
3. पेलोडमध्ये टिकाऊ event id
4. आइडेम्पोटेंट हॅंडलर मार्गदर्शन (फक्त “२०० परत करा” नाही)
5. डुप्लिकेट डिलिव्हरीवर जगणाऱ्या STOP / HELP मार्ग
6. कोणत्याही ऑटो-रिप्लाय खर्चासाठी तीच प्रीपेड वॉलेट दृश्यता

STOP, HELP आणि इतर इनबाउंड कीवर्डला तोच शिस्त

IOSOR ने सुरू करा

गेल्या आठवड्याचे आवक webhook लॉग ओढा आणि एकापेक्षा जास्त वेळा आलेले इव्हेंट ID मोजा. एक नक्कल आणि एक क्रमबाह्य जोडी चालवा (failed, मग delivered). रिसीव्हर एक परिणाम ठेवतो: एक इनबॉक्स ओळ, एक STOP लेख, एक पाकीट स्पर्श. STOP उलथवणारा last-write-wins अपयश. ही प्राप्तीवर आइडेम्पोटेन्सी आणि पुन्हा-प्रयत्न क्रम आहे, स्वाक्षरी तपासणी नाही, रांगेआधी गेटवे कुलूप नाही.

संबंधित: इनबाउंड ऑटो-रिप्लाय लूप · IOSOR मध्ये वाहक विलंबनाविरुद्ध इनबाउंड वेबहूक बफर कॉन्फिगरेशन · पहिल्या डेबिटपूर्वी प्रीपेड रक्कम राखीव ठेवणे.

IOSOR सारांश

आवक webhook पुन्हा प्रयत्न करतात. प्राप्तीवर आइडेम्पोटेन्सीच सुरक्षित उत्तर आहे; क्रम वचन नाही.

करा: इव्हेंटला कळ द्या आणि जुळे दुर्लक्षित करा. करू नका: STOP वर last-write-wins किंवा त्याच इव्हेंटवर दोन कपाती नाहीत.