तीसरे-पक्ष API का सुरक्षित एकीकरण: रीट्राई, टाइमआउट, सर्किट-ब्रेकर

क्यों तीसरे-पक्ष APIs आपके मुख्य वर्कफ़्लो को जाम कर सकते हैं

एक तीसरे-पक्ष API ऐसे तरीके से फेल हो सकता है जो साफ़ "डाउन" इवेंट जैसा न दिखे। सबसे सामान्य समस्या है धीमापन: अनुरोध अटक जाते हैं, उत्तर देर से आते हैं, और आपकी ऐप इंतजार करती रहती है। अगर ये कॉल क्रिटिकल पाथ पर हैं, तो आपके सिस्टम के अंदर बाहरी छोटे से झटके जमा होने लगते हैं।

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

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

लक्ष्य सरल है: बाहरी विफलताओं को अलग करना ताकि कोर वर्कफ़्लो चलते रहें। इसका मतलब हो सकता है कि आप ऑर्डर स्वीकार कर लें और बाद में पेमेंट कन्फर्म करें, या साइनअप की अनुमति दें भले ही वेलकम ईमेल फेल हो गया हो।

एक व्यावहारिक सफलता मीट्रिक: जब कोई प्रदाता स्लो या डाउन हो, तब भी आपकी ऐप तेजी से और स्पष्ट रूप से उत्तर दे, और प्रभाव का दायरा छोटा रहे। उदाहरण के लिए, अधिकांश कोर अनुरोध सामान्य लैटेंसी बजट के भीतर खत्म हों, विफलताएँ उन फ़ीचर तक सीमित रहें जो वाकई उस API पर निर्भर हैं, उपयोगकर्ताओं को स्पष्ट स्टेटस दिखे (queued, pending, try again later), और प्रदाता लौटने पर रिकवरी स्वतः हो जाए।

जिन विफलता मोड्स की योजना बनानी चाहिए

अधिकांश विफलताएँ भविष्यवाणी योग्य होती हैं, भले ही उनका समय नहीं। इन्हें पहले से नाम दें और आप तय कर सकेंगे क्या रीट्राई करना है, क्या रोकना है, और उपयोगकर्ता को क्या दिखाना है।

सामान्य श्रेणियाँ:

• लैटेन्सी स्पाइक्स (अनुरोध अचानक 10x तक लंबा हो जाते हैं)
• ट्रांज़िएंट सर्वर या नेटवर्क त्रुटियाँ (टाइमआउट, 502/503, कनेक्शन रिसेट)
• रेट लिमिट्स और कोटा खपत (429, दैनिक कैप)
• ऑथ और परमिशन समस्याएँ (एक्सपायर्ड कुंजियाँ, रिवॉक्ड एक्सेस)
• खराब या अचरज वाली डेटा (मिसिंग फ़ील्ड, गलत फॉर्मैट, आंशिक उत्तर)

हर त्रुटि एक जैसी नहीं होती। ट्रांज़िएंट इश्यूज़ अक्सर रीट्राई के लायक होते हैं क्योंकि अगली कॉल सफल हो सकती है (नेटवर्क ब्लिप्स, टाइमआउट, 502/503, और कुछ 429 प्रतीक)। स्थायी समस्याएँ आम तौर पर स्वयं ठीक नहीं होंगी (अमान्य क्रेडेंशियल, गलत एंडपॉइंट, मलफ़ॉर्म्ड रिक्वेस्ट, परमिशन डिनायल)।

हर त्रुटि को समान मान लेना एक छोटे incident को डाउनटाइम में बदल देता है। स्थायी विफलताओं को रीट्राई करना समय बर्बाद करता है, रेट लिमिट्स जल्दी हिट करते हैं, और बैकलॉग बनता है जो बाकी सब कुछ धीमा कर देता है। ट्रांज़िएंट विफलताओं को बिल्कुल भी रीट्राई न करना उपयोगकर्ताओं को कार्य दोहराने के लिए मजबूर करता है और उस काम को खो देता है जो कुछ ही पलों में पूरा हो सकता था।

उन वर्कफ़्लो पर विशेष ध्यान दें जहाँ रोकना टूटने जैसा महसूस होता है: चेकआउट, लॉगिन, पासवर्ड रीसेट, और नोटिफिकेशन (ईमेल/SMS/push)। एक मार्केटिंग API में दो सेकंड का स्पाइक परेशान कर सकता है। पेमेंट ऑथराइज़ेशन में दो सेकंड का स्पाइक राजस्व को ब्लॉक कर देता है।

एक सहायक परीक्षण है: "क्या यह कॉल अभी उपयोगकर्ता के मुख्य काम को पूरा करने के लिए ज़रूरी है?" अगर हाँ, तो आपको तंग टाइमआउट, सावधान रीट्राई, और स्पष्ट फेल्योर पाथ चाहिए। अगर नहीं, तो इसे कतार में भेज दें और ऐप को प्रतिक्रियाशील रखें।

टाइमआउट: एक सीमा चुनें और उस पर टिके रहें

टाइमआउट वह अधिकतम समय है जिसके बाद आप रुककर आगे बढ़ते हैं। स्पष्ट सीमा के बिना, एक स्लो प्रदाता इंतजार करते हुए अनुरोधों का ढेर बना सकता है और महत्वपूर्ण काम ब्लॉक कर सकता है।

दो तरह के इंतजार को अलग करना मदद करता है:

• कनेक्ट टाइमआउट: कनेक्शन स्थापित करने के लिए आप कितनी देर कोशिश करेंगे।
• रीड टाइमआउट: कनेक्ट होने के बाद उत्तर के लिए आप कितनी देर प्रतीक्षा करेंगे।

नंबर चुनना परफेक्शन का सवाल नहीं है। यह मानव धैर्य और आपके वर्कफ़्लो से मेल खाने का सवाल है।

• अगर उपयोगकर्ता स्पिनर देख रहा है, तो आपको आम तौर पर तेज़ उत्तर और स्पष्ट अगला कदम चाहिए।
• अगर यह बैकग्राउंड जॉब है (जैसे रात में इनवॉइस सिंक करना), तो आप अधिक समय दे सकते हैं, लेकिन फिर भी एक सीमा होनी चाहिए ताकि यह कभी अनंत तक न अटके।

समय चुनने का व्यावहारिक तरीका अनुभव से पीछे की ओर काम करना है:

• उपयोगकर्ता कितनी देर तक इंतजार कर सकता है इससे पहले कि आपको स्पष्ट संदेश दिखाना पड़े?
• अगर यह कॉल अभी फेल हो गई, क्या आप बाद में रीट्राई कर सकते हैं या फॉलबैक यूज़ कर सकते हैं?
• पीक लोड पर इन कॉलों की संख्या कितनी है?

ट्रेडऑफ वास्तविक है। बहुत लंबा रखने से आप थ्रेड्स, वर्कर और डेटाबेस कनेक्शन्स बाँध लेते हैं। बहुत छोटा रखने से आप गलत फेल्यर्स बनाएंगे और अनावश्यक रीट्राइज़ ट्रिगर करेंगे।

ऐसे रीट्राइज़ जो आउटेज को बदतर न बनाएं

रीट्राइज़ तब मदद करते हैं जब विफलता अस्थायी हो: एक छोटा नेटवर्क इश्यू, DNS हिचकी, या एक-बार 500/502/503। ऐसी स्थितियों में, दूसरी कोशिश सफल हो सकती है और उपयोगकर्ता को फर्क महसूस भी नहीं होगा।

जो खतरा है वह है रीट्राई स्टॉर्म। जब कई क्लाइंट एक साथ फेल होते हैं और सभी एक साथ रीट्राई करते हैं, तो वे प्रदाता (और आपके अपने वर्कर) को ओवरलोड कर सकते हैं। बैकऑफ़ और जिटर इसे रोकते हैं।

एक रीट्राई बजट आपको ईमानदार रखता है। प्रयासों को कम रखें और कुल समय को कैप करें ताकि कोर वर्कफ़्लो किसी और पर इंतजार न करते रहें।

एक सुरक्षित डिफ़ॉल्ट रीट्राई रेसिपी

• केवल कुछ बार रीट्राई करें (अक्सर कुल 1-3 प्रयास, फ्लो पर निर्भर)।
• एक्सपोनेंशियल बैकऑफ़ का उपयोग करें (उदाहरण 200ms, 500ms, 1s) और साथ में रैंडम जिटर डालें।
• रीट्राई में लगने वाले कुल समय को कैप करें (उपयोगकर्ता-फेसिंग फ्लो में अक्सर कुछ सेकंड)।
• हर प्रयास के लिए एक प्रति-प्रयास टाइमआउट रखें बजाय एक लंबे टाइमआउट के।

400/422 जैसी पूर्वानुमानित क्लाइंट त्रुटियों, 401/403 ऑथ समस्याओं, या 404s को रीट्राई न करें। वे लगभग हमेशा फिर से फेल होंगे और सिर्फ़ लोड बढ़ाते हैं।

एक और गार्डरेल: केवल तभी लिखने (POST/PUT) को रीट्राई करें जब आपके पास इडेम्पोटेंसी हो, वरना आप दोगुना चार्ज या डुप्लिकेट रिकॉर्ड्स का जोखिम उठाते हैं।

इडेम्पोटेंसी: वास्तविक वर्कफ़्लो के लिए रीट्राइज़ को सुरक्षित बनाना

इडेम्पोटेंसी का अर्थ है कि आप एक ही अनुरोध को दो बार चलाकर भी वही अंतिम परिणाम पा सकते हैं। यह इसलिए ज़रूरी है क्योंकि रीट्राई सामान्य है: नेटवर्क ड्रॉप, सर्वर रीस्टार्ट और क्लाइंट टाइमआउट होते रहते हैं। इडेम्पोटेंसी के बिना, एक "मददगार" रीट्राई डुप्लिकेट बना देता है और वास्तविक धन संबंधी समस्याएँ पैदा कर सकता है।

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

समाधान है कि हर "कुछ करो" कॉल के साथ एक इडेम्पोटेंसी की (या रिक्वेस्ट ID) जोड़ें। यह उपयोगकर्ता क्रिया के लिए यूनिक होना चाहिए, प्रति प्रयास नहीं। प्रदाता (या आपकी सर्विस) उस की का उपयोग डुप्लिकेट्स का पता लगाने और वही परिणाम लौटाने के लिए करता है बजाय कार्रवाई दोहराने के।

इडेम्पोटेंसी की को उस हेडर जैसा मत समझिए जो आप उम्मीद करते हैं कि कोई भूल न जाए—इसे डेटा मॉडल का हिस्सा बनाकर रखें।

प्रोडक्शन में टिकने वाला पैटर्न

जब उपयोगकर्ता एक्शन शुरू करता है (उदाहरण के लिए, तब जब वे "Pay" क्लिक करते हैं) तो एक की जेनरेट करें और उसे अपने लोकल रिकॉर्ड के साथ स्टोर करें।

हर प्रयास पर:

• वही की भेजें।
• वापस आया अंतिम परिणाम स्टोर करें (सक्सेस रिस्पॉन्स, फेलियर कोड, चार्ज ID)।
• अगर आपके पास पहले से रिकॉर्डेड आउटकम है, तो वही आउटकम लौटाएं बजाय कार्रवाई दोहराने के।

अगर आप आंतरिक कॉल के "प्रोवाइडर" हैं, तो सर्वर-साइड वही व्यवहार लागू करें।

सर्किट ब्रेकर: जब API फेल कर रहा हो तो कॉल रोकना

सर्किट ब्रेकर एक सुरक्षा स्विच है। जब कोई बाहरी सेवा फेल होने लगे, आप अल्पकाल के लिए उसे कॉल करना बंद कर देते हैं बजाय इस के कि और अनुरोध जमा कर दें जो शायद टाइमआउट होंगे।

सर्किट ब्रेकर आम तौर पर तीन राज्यों में होते हैं:

• Closed: अनुरोध सामान्य रूप से चलते हैं।
• Open: कॉल्स एक कूलडाउन विंडो के लिए ब्लॉक होते हैं।
• Half-open: कूलडाउन के बाद कुछ परीक्षण कॉल्स यह जाँचते हैं कि सेवा रिकवर हुई है या नहीं।

जब ब्रेकर ओपन होता है, आपकी ऐप को कुछ पूर्वानुमानित करना चाहिए। अगर साइनअप के दौरान पता सत्यापन API डाउन है, तो पता स्वीकार करें और बाद में समीक्षा के लिए मार्क करें। अगर पेमेंट रिस्क चेक डाउन है, तो ऑर्डर को मैन्युअल समीक्षा के लिए कतारबद्ध करें या अस्थायी रूप से वह विकल्प अक्षम कर दें और स्पष्ट करें।

ऐसे थ्रेशहोल्ड चुनें जो उपयोगकर्ता प्रभाव से मेल खाते हों:

• लगातार त्रुटियाँ (उदाहरण 5 फेल्योर लगातार)
• छोटे विंडो में उच्च फेल्योर रेट
• कई स्लो रिस्पॉन्स (टाइमआउट)
• कुछ विशेष स्टेटस कोड्स (जैसे बार-बार 503)

कूलडाउन को छोटा रखें (सेकंड से एक मिनट) और हाफ-ओपन प्रोब्स सीमित रखें। उद्देश्य है पहले कोर वर्कफ़्लो की रक्षा, फिर तेज़ी से रिकवरी।

फॉलबैक और कतारें: ऐप को उपयोगी रखें

जब कोई बाहरी API स्लो या डाउन हो, तो आपका लक्ष्य उपयोगकर्ता को आगे बढ़ाना है। इसका मतलब है एक प्लान बी होना जो ईमानदार हो कि क्या हुआ।

फॉलबैक: "अच्छा-पर्याप्त" अनुभव चुनें

फॉलबैक वह होता है जो आपकी ऐप तब करती है जब API समय पर उत्तर नहीं दे पाता। विकल्पों में कैश्ड डेटा का उपयोग, डिग्रेडेड मोड (नॉन-एसेन्शियल विजेट छुपाना, वैकल्पिक क्रियाओं को डिसेबल करना), API कॉल के बजाय उपयोगकर्ता से इनपुट माँगना (मैन्युअल पता प्रविष्टि), या अगला साफ संदेश दिखाना शामिल हैं।

ईमानदार रहें: ऐसा न कहें कि कुछ पूरा हो गया अगर वह नहीं हुआ।

कतारें: तब करें जब "अब" ज़रूरी न हो

अगर काम उपयोगकर्ता अनुरोध के अंदर पूरी तरह खत्म होना ज़रूरी नहीं है, तो उसे कतार में डालें और जल्दी उत्तर दें। सामान्य उम्मीदवार: ईमेल भेजना, CRM में सिंक करना, रिपोर्ट जनरेट करना, और एनालिटिक्स इवेंट पोस्ट करना।

कोर क्रियाओं के लिए फेल फ़ास्ट करें। अगर कोई API चेकआउट (या अकाउंट क्रिएशन) पूरा करने के लिए आवश्यक नहीं है, तो अनुरोध को ब्लॉक न करें। ऑर्डर स्वीकार करें, बाहरी कॉल को कतारबद्ध करें, और बाद में रिकन्साइल करें। अगर API आवश्यक है (उदाहरण के लिए पेमेंट ऑथराइज़ेशन), तो जल्दी फेल करें एक स्पष्ट संदेश के साथ और उपयोगकर्ता को इंतजार मत कराएं।

उपयोगकर्ता को जो दिखे वह बैकएंड में होने वाली चीज़ के अनुरूप होना चाहिए: एक साफ़ स्टेटस (completed, pending, failed), एक वादा जिसे आप निभा सकते हैं (रसीद अभी, कन्फर्मेशन बाद में), रीट्राई करने का तरीका, और UI में एक दृश्य रिकॉर्ड (एक्टिविटी लॉग, pending बैज)।

रेट लिमिट्स और लोड: खुद से होने वाली विफलताओं से बचें

रेट लिमिट्स प्रदाता का तरीका है यह कहने का, "आप हमें कॉल कर सकते हैं, पर बहुत बार नहीं।" आप इन्हें अपेक्षा से जल्दी हिट कर लेंगे: ट्रैफ़िक स्पाइक्स, बैकग्राउंड जॉब्स एक साथ फायर करना, या कोई बग जो एरर पर लूप कर दे।

शुरुआत करें यह नियंत्रित करके कि आप कितने अनुरोध बनाते हैं। जहां संभव हो बैच करें, सुरक्षित होने पर 30-60 सेकंड के लिए रिस्पॉन्स कैश करें, और क्लाइंट साइड पर थ्रॉटल करें ताकि आपकी ऐप प्रदाता की अनुमति से तेज़ नहीं फटे।

जब आप 429 Too Many Requests पाते हैं, तो इसे धीमा होने का संकेत समझें:

• अगर Retry-After दिया गया है तो उसका सम्मान करें।
• कई वर्कर्स एक ही क्षण में रीट्राई न करें—जिटर जोड़ें।
• 429 के लिए रीट्राई को कैप करें ताकि अनंत लूप न बने।
• बार-बार 429 पर अधिक आक्रामक बैकऑफ़ लागू करें।
• इसे एक मेट्रिक के रूप में रिकॉर्ड करें ताकि आप उपयोगकर्ताओं से पहले पैटर्न नोटिस कर सकें।

कन्सकरेंसी को भी सीमित करें। एक ही वर्कफ़्लो (जैसे कॉन्टैक्ट्स सिंक करना) सभी वर्कर स्लॉट्स नहीं खपत करना चाहिए और लॉगिन या चेकआउट जैसे महत्वपूर्ण फ्लो को भूखा नहीं रखना चाहिए। अलग-पूल्स या प्रति-फ़ीचर कैप मदद करते हैं।

कदम-दर-कदम: एक सुरक्षित डिफ़ॉल्ट इंटीग्रेशन रेसिपी

हर तीसरे-पक्ष कॉल के लिए विफलता की योजना होनी चाहिए। परफेक्शन की ज़रूरत नहीं। आपको ऐसी उम्मीदयोग्य व्यवहार चाहिए जब प्रदाता का बुरा दिन हो।

1) कॉल को वर्गीकृत करें (जरूरी बनाम प्रतीक्षा कर सकता है)

यह तय करें कि अगर कॉल अभी फेल हो जाए तो क्या होगा। चेकआउट के दौरान टैक्स कैलकुलेशन जरूरी हो सकता है। मार्केटिंग कॉन्टैक्ट सिंक आम तौर पर इंतजार कर सकता है। यह चुनाव बाकी सब को ड्राइव करेगा।

2) टाइमआउट और रीट्राई बजट सेट करें

कॉल प्रकार के अनुसार टाइमआउट चुनें और उन्हें सुसंगत रखें। फिर एक रीट्राई बजट सेट करें ताकि आप स्लो API पर लगातार वार न करते रहें।

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

3) इडेम्पोटेंसी और ट्रैकिंग के साथ रीट्राइज़ सुरक्षित बनाएं

अगर एक अनुरोध कुछ बना सकता है या पैसा चार्ज कर सकता है, तो इडेम्पोटेंसी की जोड़ें और एक रिक्वेस्ट रिकॉर्ड स्टोर करें। अगर पेमेंट रिक्वेस्ट टाइमआउट हो, तो रीट्राई डबल-चार्ज नहीं होना चाहिए। ट्रैकिंग से सपोर्ट को भी मदद मिलती है यह बताने में "क्या हुआ?"

4) सर्किट ब्रेकर और फॉलबैक व्यवहार जोड़ें

जब त्रुटियाँ स्पाइक करें, तब प्रदाता को कॉल करना बंद कर दें थोड़े समय के लिए। जरूरी कॉल्स के लिए एक स्पष्ट "Try again" पाथ दिखाएँ। प्रतीक्षा योग्य कॉल्स के लिए काम को कतारबद्ध करें और बाद में प्रोसेस करें।

5) मूल बातें मॉनिटर करें

लेटेंसी, एरर रेट, और ब्रेकर ओपन/क्लोज़ इवेंट्स ट्रैक करें। सस्टेन्ड बदलावों पर अलर्ट दें, न कि एकल ब्लिप पर।

आम गलतियाँ जो छोटे मुद्दे को डाउनटाइम बना देती हैं

अधिकांश API आउटेज बड़े नहीं शुरू होते। वे तब बड़े होते हैं जब आपकी ऐप सबसे खराब तरीके से प्रतिक्रिया करती है: बहुत देर तक इंतजार करना, बहुत आक्रामक रीट्राइज़ करना, और उन्हीं वर्कर्स को बाँध लेना जो बाकी सब चलाते हैं।

ये पैटर्न कैस्केड्स पैदा करते हैं:

• हर विफलता को रीट्राई करना, जिनमें 4xx समस्याएँ भी शामिल हैं जैसे अमान्य अनुरोध, एक्सपायर्ड ऑथ, या मिसिंग परमिशन।
• बहुत लंबे टाइमआउट सेट करना "सुरक्षित रहने के लिए," जो चुपचाप थ्रेड्स, DB कनेक्शन्स या जॉब रनर्स को खा लेते हैं जब तक क्षमता खत्म न हो जाए।
• इडेम्पोटेंसी कुंजी के बिना क्रिएट एक्शन्स को रीट्राई करना, जिसके परिणामस्वरूप डबल चार्ज, डुप्लिकेट शिपमेंट, या बार-बार रिकॉर्ड बनते हैं।
• गलत कॉन्फ़िगर सर्किट ब्रेकर जो कभी रिकवर नहीं करते या बार-बार खुलते और बंद होते रहते हैं।
• आंशिक आउटेज को कुल विफलता मान लेना बजाय केवल प्रभावित फ़ीचर को degrade करने के।

छोटी फ़िक्सेस बड़े आउटेज रोकते हैं: केवल उन त्रुटियों को रीट्राई करें जो अस्थायी होने की संभावना रखते हैं (टाइमआउट, कुछ 429, कुछ 5xx) और प्रयासों को बैकऑफ़ व जिटर के साथ कैप करें; टाइमआउट को छोटा और इरादतन रखें; किसी भी ऑपरेशन के लिए जो क्रिएट/चार्ज करता है इडेम्पोटेंसी ज़रूरी करें; और आंशिक आउटेज के लिए डिज़ाइन करें।

शिप करने से पहले जल्दी चेकलिस्ट

प्रोडक्शन में एकीकरण पुश करने से पहले विफलता के नजरिए से एक तेज पास करें। अगर आप किसी आइटम का "हाँ" में जवाब नहीं दे सकते, उसे रिलीज़ ब्लॉकर मानें—खासकर कोर वर्कफ़्लो के लिए जैसे साइनअप, चेकआउट, या संदेश भेजना।

• टाइम लिमिट्स स्पष्ट हैं (कनेक्ट टाइमआउट और रीड/रिस्पॉन्स टाइमआउट)।
• रीट्राइज़ सीमित हैं (छोटा रीट्राई बजट, बैकऑफ़, जिटर, और कुल समय कैप)।
• रीट्राइज़ असली क्रियाओं के लिए सुरक्षित हैं (इडेम्पोटेंसी कीज़ या स्पष्ट डुप्लीकेट जाँच)।
• एक ब्रेकर और प्लान बी है (फॉलबैक, डिग्रेडेड मोड, या कतार)।
• आप समस्याओं को जल्दी देख सकते हैं (लेटेंसी, एरर रेट, और प्रत्येक प्रदाता/एंडपॉइंट की हेल्थ)।

अगर कोई पेमेंट प्रदाता टाइमआउट होने लगे, तो सही व्यवहार है "चेकआउट अभी भी लोड होता है, उपयोगकर्ता को स्पष्ट संदेश मिलता है, और आप अनंत तक नहीं घूमते," न कि "सब कुछ तब तक अटका रहे जब तक टाइमआउट न हो जाए।"

उदाहरण: जब कोई प्रदाता अस्थिर हो तो चेकआउट की रक्षा

मान लें एक चेकआउट तीन सेवाओं को कॉल करता है: कार्ड चार्ज करने के लिए पेमेंट API, टैक्स कैलकुलेट करने के लिए टैक्स API, और रसीद भेजने के लिए ईमेल API।

पेमेंट कॉल ही एकमात्र ऐसी कॉल है जिसे सिंक्रोनस होना चाहिए। टैक्स या ईमेल की समस्याएँ खरीदारी को जाम नहीं करनी चाहिए।

जब टैक्स API स्लो हो

मान लीजिए टैक्स API कभी-कभी 8 से 15 सेकंड ले लेता है। अगर चेकआउट इंतजार करे, उपयोगकर्ता कार्ट छोड़ देते हैं और आपकी ऐप वर्कर फंस जाते हैं।

एक सुरक्षित फ्लो:

• एक हार्ड टाइमआउट सेट करें (उदाहरण 800ms से 2s) और तेज़ी से फेल करें।
• केवल एक बार अधिकतम रीट्राई करें, और वह भी तभी जब सुरक्षित हो, और जिटर के साथ।
• टाइमआउट पर, खरीददार के क्षेत्र के लिए कैश्ड रेट या अंतिम ज्ञात तालिका का उपयोग करें।
• अगर कानूनी रूप से कैश्ड रेट नहीं इस्तेमाल कर सकते, तो ऑर्डर को "pending tax" चिह्नित करें और रीकैलकुलेशन कतारबद्ध करें।

परिणाम: कम छोड़े गए कार्ट और कम अटके हुए ऑर्डर जब टैक्स प्रदाता स्लो हो।

जब ईमेल API डाउन हो

रसीद ईमेल महत्वपूर्ण है, लेकिन इसे भुगतान कब्जे को कभी ब्लॉक नहीं करना चाहिए। अगर ईमेल API फेल कर रहा है, तो कुछ तेज़ फेल्योर के बाद सर्किट ब्रेकर खुल जाना चाहिए और कॉल्स को थोड़े समय के लिए रोक देना चाहिए।

ईमेल इनलाइन भेजने के बजाय, "send receipt" जॉब को एक इडेम्पोटेंसी की के साथ कतारबद्ध करें (उदा. order_id + email_type)। अगर प्रदाता डाउन है, कतार बैकग्राउंड में रीट्राई करेगी और ग्राहक को फिर भी सफल खरीद दिखाई देगी।

परिणाम: कमी सपोर्ट टिकट्स और चेकआउट का न होना गैर-भुगतान कारणों से राजस्व की हानि को रोकता है।

अगले कदम: अपनी ऐप में सुरक्षित रूप से रोल आउट करें

एक वर्कफ़्लो चुनें जो टूटने पर सबसे अधिक नुकसान पहुँचाता है (चेकआउट, साइनअप, इनवॉइसिंग) और उसे अपना संदर्भ इंटीग्रेशन बनाइए। फिर वही डिफॉल्ट्स हर जगह कॉपी करें।

एक सरल रोलआउट क्रम:

• टाइमआउट सेट करें और तेज़ी से फेल के साथ स्पष्ट त्रुटि दिखाएँ।
• रीट्राइज़ बैकऑफ़ के साथ जोड़ें, पर केवल रीट्राईएबल त्रुटियों के लिए।
• इडेम्पोटेंसी जोड़ें ताकि रीट्राई डबल-चार्ज या डबल-क्रिएट न कर सके।
• सर्किट ब्रेकर जोड़ें ताकि एक खराब प्रदाता आपके कोर वर्कफ़्लो को जाम न कर सके।

अपने डिफॉल्ट्स लिख कर रखें और उन्हें उबाऊ रखें: एक कनेक्ट टाइमआउट, एक रिक्वेस्ट टाइमआउट, अधिकतम रीट्राई काउंट, बैकऑफ़ रेंज, ब्रेकर कूलडाउन, और क्या रीट्राईयोग्य है की नियमावली।

अगले वर्कफ़्लो पर विस्तार करने से पहले एक फेल्योर ड्रिल चलाएँ। टेस्ट एनवायरनमेंट में टाइमआउट फोर्स करें (या प्रदाता ब्लॉक करें), फिर पुष्टि करें कि उपयोगकर्ता को उपयोगी संदेश दिखे, फॉलबैक काम करें, और कतारबद्ध रीट्राइज़ कभी भी अनंत न बनें।

यदि आप जल्दी नए प्रोडक्ट बना रहे हैं, तो इन भरोसेमंद डिफॉल्ट्स को एक पुन:उपयोगी टेम्पलेट में बदलना लाभदायक है। Koder.ai (koder.ai) इस्तेमाल करने वाली टीमों के लिए, इसका मतलब अक्सर है कि टाइमआउट, रीट्राई, इडेम्पोटेंसी, और ब्रेकर नियम एक बार परिभाषित करें और फिर नए सर्विसेज में वही पैटर्न लागू करें।