ऐसे SMM API इंटीग्रेशन डिज़ाइन करना जो विफलता से बच जाएँ

हर API इंटीग्रेशन का पहला वर्ज़न हैप्पी पाथ मान लेता है: आप एक रिक्वेस्ट भेजते हैं, आपको एक रिस्पॉन्स मिलता है, ऑर्डर लग जाता है। प्रोडक्शन आपको कुछ और सिखाता है। नेटवर्क टूटते हैं, एंडपॉइंट टाइम-आउट होते हैं, और सबसे ख़तरनाक विफलता वह अस्पष्ट वाली है। वह रिक्वेस्ट जो कनेक्शन टूटने से पहले सफल हुई भी हो सकती है और नहीं भी। उसी अस्पष्टता के लिए डिज़ाइन करना ही पूरा काम है।

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

ऊपर से रीट्राई को बैकऑफ़ के साथ परतबद्ध करें। अस्थायी एरर (एक 429 रेट लिमिट, एक 503, एक नेटवर्क रीसेट) को बढ़ती हुई देरी और एक सीमा के साथ रीट्राई करना चाहिए, न कि तुरंत बार-बार ठोकना। स्थायी एरर (एक 400 बैड रिक्वेस्ट, एक अपर्याप्त-बैलेंस रिस्पॉन्स) को जल्दी विफल होकर किसी इंसान के सामने आना चाहिए, क्योंकि उन्हें रीट्राई करना सिर्फ़ समय बर्बाद करता है और असली समस्या को छुपा देता है।

आख़िर में, मिलान करें। हर रिक्वेस्ट और रिस्पॉन्स को उसकी आइडमपोटेंसी की और ऑर्डर ID के साथ लॉग करें, और एक आवधिक जॉब चलाएँ जो आपके रिकॉर्ड की तुलना पैनल की ऑर्डर स्थितियों से करे। रिकंसिलिएशन ही वह है जो उस ऑर्डर को पकड़ता है जो पैनल पर सफल हुआ पर आपकी ओर रिकॉर्ड होने में विफल रहा। SocialGO का API एक समान ऑर्डर ID और स्थितियाँ ख़ास तौर पर इसलिए लौटाता है ताकि यह लूप बनाना आसान हो, उस ऑटोमेशन और उस ऑटोमेशन के बीच का फ़र्क जिस पर आप भरोसा करते हैं और जिसकी देखभाल करनी पड़ती है।