विजुअल वर्कफ़्लोज़ में थर्ड‑पार्टी API के लिए सर्किट ब्रेकर पैटर्न

थर्ड‑पार्टी API आउटेज कई फीचर क्यों तोड़ते हैं

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

इसीलिए सर्किट ब्रेकर अहम है। यह सिद्धांत नहीं सिर्फ एक व्यावहारिक तरीका है ताकि एक इंटीग्रेशन अनहेल्दी होने पर भी कोर संचालन चलते रहें।

धीमा और डाउन अलग तरह से नुकसान पहुंचाते हैं।

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

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

सामान्य लक्षण जल्दी दिख जाते हैं: टाइमआउट, बढ़ती कतारें, आंशिक अपडेट, और बहुत सारा मैन्युअल क्लीनअप।

असल नुकसान चेन‑रिएक्शन है। अगर शिपिंग‑रेट प्रोवाइडर धीमा है, तो ऑर्डर प्लेसमेंट धीमा होगा क्योंकि वर्कफ़्लो को कोट के बिना ऑर्डर कन्फर्म करने से इंकार हो सकता है। अगर पेमेंट्स डाउन हैं, तो सपोर्ट रिफंड जारी करने से ब्लॉक हो सकता है भले ही बाकी सब काम कर रहा हो।

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

सर्किट ब्रेकर सरल शब्दों में

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

सर्किट ब्रेकर के तीन सरल परिणाम होते हैं:

• कॉल की अनुमति देना जब विक्रेता स्वस्थ दिखे।
• कॉल को ब्लॉक करना जब विफलताएँ अधिक हों, और तुरंत फॉलबैक पाथ अपनाना।
• छोटी टेस्ट कॉल आज़माना एक छोटे विराम के बाद यह देखने के लिए कि विक्रेता वापस आया है या नहीं।

यदि आप लेबल पसंद करते हैं, तो ये “closed”, “open”, और “half‑open” हैं। नाम मायने नहीं रखते — अपेक्षाकृत व्यवहार मायने रखता है। जब वेंडर बीमार है, तो आपका वर्कफ़्लो हर बार एक ही तरह व्यवहार करना चाहिए।

यह त्रुटियों को छिपाता नहीं है। आप विफलताओं को रिकॉर्ड करते हैं, उपयोगकर्ता या ऑप्स को स्पष्ट स्टेटस दिखाते हैं, और सही लोगों को अलर्ट करते हैं। आप तय करते हैं कि तेज़ी से फेल करना है, काम को सुरक्षित विकल्प पर रूट करना है, या थोड़ी देर रुक कर फिर से टेस्ट करना है।

तय करें कौन‑सी API कॉल्स बिज़नेस को कभी नहीं रोकेंगी

सर्किट ब्रेकर तब बेहतर काम करता है जब आप चयनात्मक हों। हर वेंडर कॉल को विशेष सुरक्षा की ज़रूरत नहीं होती। उन स्टेप्स से शुरू करें जो ब्लॉक होने पर पैसे, ऑर्डर, या ग्राहक पहुंच रोक दें।

एक व्यावहारिक तरीका है एक उपयोगकर्ता अनुरोध को एंड‑टू‑एंड फॉलो करना। किस जगह पर टाइमआउट होने पर उपयोगकर्ता कार्य छोड़ देगा, या ऐसी गड़बड़ी होगी जिसे आपकी टीम बाद में साफ़ करने को बाध्य होगी?

आम तौर पर "कोर वर्क को ब्लॉक ना करने" वाली कॉल्स में शामिल हैं: पेमेंट्स, शिपिंग/फुलफिलमेंट, लॉगिन/SSO/MFA, OTP और पुष्टि संदेश, और अनुमोदन से जुड़ी कंप्लायंस चेक्स।

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

छोटे से शुरू करें ताकि स्कोप क्रेप न हो। पहले 1–3 वर्कफ़्लोज़ को प्रोटेक्ट करें, फिर विस्तार करें।

किसी भी निर्माण से पहले “सुरक्षित फॉलबैक” का क्या अर्थ है यह परिभाषित करें। अच्छे फॉलबैक्स विशिष्ट और टेस्ट करने योग्य होते हैं:

• पेमेंट्स: ऑर्डर को “payment pending” के रूप में सहेजें ताकि कार्ट खो न जाए।
• शिपिंग: कैश्ड रेट, फ्लैट रेट, या ऑर्डर कन्फर्म करना और लेबल खरीद को बाद में टालना।
• पहचान: जब SSO डाउन हो तब पासवर्ड लॉगिन की अनुमति दें, या ईमेल वेरिफिकेशन पर स्विच करें।
• मैसेजिंग: SMS को बाद में कतारबद्ध करें और जहाँ संभव हो वैकल्पिक पाथ दें।

AppMaster के Business Process Editor में यह आम तौर पर एक साफ़ ब्रांच बन जाता है: कोर ऑपरेशन जारी रहता है, जबकि विक्रेता‑निर्भर स्टेप नियंत्रित विकल्प लेता है।

स्टेट्स, थ्रेशहोल्ड्स, और टाइमर जिन्हें आप समझा सकते हैं

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

तीन स्टेट्स

Closed सामान्य है। आप API कॉल करते हैं और आगे बढ़ते हैं।

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

कूलडाउन के बाद ब्रेकर Half‑open होता है। आप कुछ टेस्ट कॉल की अनुमति देते हैं। अगर वे सफल होते हैं तो Closed पर लौट आते हैं, नहीं तो फिर से Open हो जाते हैं।

क्या नापना चाहिए

वह संकेत चुनें जो यह बताता हो कि वेंडर किस तरह विफल होता है:

• टाइमआउट
• HTTP 5xx त्रुटियाँ
• बढ़ती लेटेन्सी (बहुत धीमी होने पर उपयोगी नहीं)
• कनेक्शन/DNS त्रुटियाँ
• 429 रेट‑लिमिट

विज़ुअल वर्कफ़्लो टूल में ये आम तौर पर सरल चेक्स में मैप होते हैं: स्टेटस कोड, बीता हुआ समय, और विशिष्ट एरर आउटपुट।

शुरुआती थ्रेशहोल्ड और दो प्रमुख टाइमर

ऐसे नंबर चुने जो समझाने में आसान हों, फिर वास्तविक ट्रैफ़िक के आधार पर ट्यून करें। उदाहरण:

• 30–60 सेकंड में 5–10 कॉल्स फेल होने पर ब्रेकर खोलें।
• या रोलिंग विंडो में 20%–40% कॉल्स फेल हों तो खोलें।
• विलंब को तब विफल मानें जब यह आपके प्रोसेस के लिए असहनीय हो (अक्सर 2–5 सेकंड)।

फिर दो टाइमर सेट करें:

• Cooldown time (Open state): अक्सर 30 सेकंड से 5 मिनट।
• Half‑open टेस्ट विंडो: 1–5 टेस्ट कॉल्स की अनुमति या 10–30 सेकंड जैसी छोटी विंडो।

लक्ष्य सीधा है: जब वेंडर अनहेल्दी हो तो तेज़ी से फेल करें, और जब यह वापस आए तो स्वचालित रूप से रिकवर हो जाए।

स्टेप‑बाय‑स्टेप: एक विज़ुअल वर्कफ़्लो में सर्किट ब्रेकर बनाना

सबसे महत्वपूर्ण डिज़ाइन चुनाव यह है कि “क्या हम अभी वेंडर को कॉल करें?” का निर्णय एक जगह पर लें, न कि हर वर्कफ़्लो में बिखरा हुआ।

1) वेंडर कॉल को एक पुन:उपयोग योग्य ब्लॉक के पीछे रखें

एक सब‑प्रोसेस बनाएं (एक पुन:उपयोग योग्य वर्कफ़्लो ब्लॉक) जिसे हर वर्कफ़्लो उस वेंडर की ज़रूरत पड़ने पर प्रयोग करे। AppMaster में यह Business Process के रूप में फिट बैठता है जिसे आप एंडपॉइंट्स या ऑटोमेशन्स से कॉल कर सकते हैं। इसे संकर रखें: इनपुट्स अंदर, वेंडर रिक्वेस्ट बाहर, और क्लियर success/fail रिज़ल्ट।

2) विफलताओं को केवल काउंट से नहीं बल्कि समय के साथ ट्रैक करें

हर परिणाम को टाइमस्टैम्प के साथ रिकॉर्ड करें। last success, last failure, विफलताएँ एक विंडो के भीतर, current state, और एक cooldown deadline जैसी चीज़ें स्टोर करें।

इन फील्ड्स को एक टेबल में टिकाए रखें ताकि ब्रेकर रिस्टार्ट के बाद भी जिंदा रहे और मल्टीपल इंस्टेंसेस में कंसिस्टेंट रहे। PostgreSQL और Data Designer इसके लिए अच्छे विकल्प हैं।

3) स्टेट चेंजेस को सरल रखें जिन्हें आप हर बार फॉलो करेंगे

नियम सरल रखें। उदाहरण: अगर 2 मिनट में 5 विफलताएँ हों तो Open कर दें। Open रहते हुए वेंडर कॉल स्किप करें जब तक cooldown पास न हो। कूलडाउन के बाद Half‑open जाएँ और एक नियंत्रित कोशिश की अनुमति दें। सफल होने पर Close कर दें; विफल होने पर फिर से Open करें।

4) वर्कफ़्लो ब्रांच करें: वेंडर पाथ बनाम फॉलबैक पाथ

वेंडर रिक्वेस्ट से पहले स्टोर किए गए स्टेट की जाँच करें:

• Closed: वेंडर को कॉल करें, फिर success या failure अपडेट करें।
• Open: कॉल स्किप करें और फॉलबैक रन करें।
• Half‑open: सीमित कोशिश की अनुमति दें, फिर बंद या फिर खोलने का निर्णय लें।

उदाहरण: अगर शिपिंग लेबल API डाउन है, तो फॉलबैक ऑर्डर बना सकता है और उसे “Label pending” स्टेटस दे सकता है और रीट्राई जॉब कतारबद्ध कर सकता है, बजाय इसके कि चेकआउट या वेयरहाउस काम रुक जाए।

5) इसे वर्कफ़्लोज़ के बीच साझा बनाएं

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

ऐसे फॉलबैक जो काम जारी रखते हैं

सर्किट ब्रेकर तभी मददगार है जब आप तय कर लें कि कॉल ब्लॉक होने पर क्या होगा। अच्छा फॉलबैक उपयोगकर्ता को आगे बढ़ाता है, आपके डेटा की सुरक्षा करता है, और बाद में reconciliation को आसान बनाता है।

फॉलबैक उस काम के मुताबिक चुनें। अगर शिपिंग‑रेट प्रोवाइडर डाउन है, तो आपको सटीक कीमत की जरूरत नहीं हो सकती ताकि ऑर्डर स्वीकार किया जा सके। विज़ुअल वर्कफ़्लो में असफल API स्टेप को ऐसे फॉलबैक ब्रांच में रूट करें जो उपयोगी परिणाम दे।

व्यवहार में फॉलबैक्स आमतौर पर इन तरह दिखते हैं:

• आखिरी ज्ञात वैल्यू का कैश्ड प्रयोग (एक स्पष्ट freshness विंडो के साथ)।
• एक सुरक्षित डिफ़ॉल्ट अनुमान, स्पष्ट लेबल के साथ।
• मैन्युअल समीक्षा के लिए रूट करना।
• काम को बाद में रीट्राई के लिए कतारबद्ध करना (async job)।

यूजर एक्सपीरियंस लॉजिक जितना ही मायने रखता है। किसी अस्पष्ट एरर को न दिखाएँ। बताएँ क्या हुआ और उपयोगकर्ता आगे क्या कर सकता है: “हम अभी रेट कन्फर्म नहीं कर पाए। आप अनुमानित शिपिंग लागत के साथ ऑर्डर कर सकते हैं, या इसे समीक्षा के लिए सहेज सकते हैं।”

छोटे बनाम लंबे आउटेज के लिए भी योजना बनाएं। छोटा आउटेज (मिनट) अक्सर मतलब होता है “आगे बढ़ो, बैकग्राउंड में रीट्राई करो।” लंबा आउटेज (घंटे) अधिक कड़ाई मांग सकता है जैसे मैन्युअल समीक्षा या अतिरिक्त अनुमोदन।

अंत में हर फॉलबैक को ट्रैक करें ताकि reconciliation आसान हो। कम से कम फॉलबैक प्रकार, मूल अनुरोध विवरण, उपयोगकर्ता को क्या लौटाया गया (और क्या वह अनुमान था), और फॉलो‑अप के लिए स्टेटस रिकॉर्ड करें।

अस्थायी ब्लॉकिंग नियम और स्मार्ट रिट्राई

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

रिट्राई अनुमान्य और सीमित होने चाहिए, और उन्हें ब्रेकर स्टेट का सम्मान करना चाहिए। व्यावहारिक नीति:

• मैक्स रिट्राई कम रखें (अक्सर 2–3)।
• एक्सपोनेंशियल बैकऑफ का उपयोग करें (उदा., 2s, 8s, 30s)।
• जिटर जोड़ें ताकि रिट्राई सिंक्रोनाइज़ न हों।
• कुल रिट्राई समय कैप करें (उदा., 60–90 सेकंड)।
• यदि ब्रेकर Open है तो रिट्राई न करें; सीधे फॉलबैक अपनाएँ।

अस्थायी ब्लॉकिंग संबंधित परंतु अलग है। यह उन मामलों के लिए है जहाँ रिस्पॉन्स कहता है “यह अभी काम नहीं करेगा।” सामान्य नियम:

• 429 रेट‑लिमिट: Retry‑After अवधि के लिए ब्लॉक करें (या सुरक्षित फिक्स्ड विंडो)।
• 401/403 ऑथ फेल्योर: क्रेडेंशियल्स रिफ्रेश होने तक ब्लॉक करें, फिर एक बार टेस्ट करें।
• लगातार 5xx: थोड़ी देर के लिए ब्लॉक करें, फिर एक छोटा टेस्ट अनुमति दें।

ब्लॉक के दौरान चल रहे काम के लिए तय करें: इसे कतारबद्ध करें, reroute करें, या graceful degrade करें (उदा., ऑर्डर स्वीकार करें पर “send SMS” देर से करें)।

अलर्टिंग जो बताती है कि क्या करना है

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

अच्छे डिफ़ॉल्ट ट्रिगर्स:

• ब्रेकर खुलते ही अलर्ट करें।
• अगर यह अपेक्षित समय से अधिक खुला रहे तो अलर्ट करें।
• खोलने से पहले ही त्रुटियों में तेज़ उछाल पर अलर्ट करें।

अलर्ट्स को actionable बनाएं। इसमें वेंडर और एंडपॉइंट, वर्तमान स्टेट और कब बदला, उपयोगकर्ता किस तरह प्रभावित होंगे, वर्कफ़्लो अब क्या कर रहा है (ब्लॉक, रिट्राई, फॉलबैक), और एक सुझाया अगला कदम शामिल करें।

सिरियसिटी के हिसाब से रूट करें। नॉन‑क्रिटिकल एनरीचमेंट API के लिए ईमेल ठीक है। पेमेंट्स, लॉगिन या ऑर्डर सबमिशन के लिए आम तौर पर पेज warranted होता है। AppMaster में यह क्लियर ब्रांचेज के रूप में मैप होता है जो severity फ्लैग के आधार पर ईमेल, Telegram, या SMS भेजते हैं।

कुछ मेट्रिक्स ट्रैक करें ताकि आप देख सकें कि आप रिकवर कर रहे हैं या नहीं: अक्सर प्रति वेंडर ब्लॉक्ड कॉल्स और फॉलबैक उपयोग ही काफी होते हैं।

उदाहरण परिदृश्य: विक्रेता आउटेज के बावजूद ऑर्डर रोके बिना

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

सामान्य दिन में, ऑर्डर बनता है, फिर वर्कफ़्लो लाइव रेट्स का अनुरोध करता है, और ऑर्डर चुने हुए कैरियर और कीमत के साथ सेव होता है।

जब वेंडर फेल होना शुरू करता है, कॉल्स टाइमआउट या 5xx एरर लौटाती हैं। एक बार आपकी थ्रेशहोल्ड पार हो जाने (उदा., 2 मिनट में 5 विफलताएँ), तो ब्रेकर खुल जाता है।

Open के दौरान, वर्कफ़्लो कुछ छोटी विंडो (मान लें 10 मिनट) के लिए शिपिंग प्रोवाइडर को कॉल करना बंद कर देता है। इससे एक फेलिंग वेंडर चेकआउट को सबके लिए धीमा करने से रोका जाता है।

चेकआउट ब्लॉक करने के बजाय फॉलबैक कर सकते हैं:

• फ्लैट‑रेट लागू करें (या सुरक्षित अनुमान)।
• ऑर्डर वैसे ही बनाएं।
• इसे “Shipping rate pending” के रूप में मार्क करें ताकि बाद में पुनर्गणना हो सके।
• वेंडर एरर विवरण फॉलो‑अप के लिए सहेजें।

AppMaster में यह Business Process Editor में एक स्पष्ट ब्रांच है, और Data Designer में shipping_rate_status और shipping_rate_source जैसे फील्ड्स द्वारा बैक किया जा सकता है।

शिप करने से पहले त्वरित जाँचें

सर्किट ब्रेकर को स्ट्रेस के दौरान उसी तरह व्यवहार करना चाहिए जैसे डेमो में करता है। रिलीज़ से पहले बेसिक्स की पुष्टि करें:

• थ्रेशहोल्ड और कूलडाउन डॉक्यूमेंटेड और बदलने में आसान हों।
• Open स्टेट तुरंत कॉल्स ब्लॉक करे (वेंडर टाइमआउट्स का इंतज़ार न करे)।
• फॉलबैक व्यवहार पैसे और ग्राहक वायदों के लिए सुरक्षित हो।
• Half‑open probing कुछ टेस्ट कॉल्स तक सीमित हो।
• लॉग्स टाइमिंग और इम्पैक्ट का जवाब देना आसान बनाते हों।

फॉलबैक सुरक्षा पर अतिरिक्त समय लगाएँ। "वर्क को आगे बढ़ाना" कुछ वित्तीय जोखिम भी ला सकता है। अगर पेमेंट प्रोवाइडर डाउन है, तो ऑर्डरों को paid मार्क करना खतरे से भरा है। एक सुरक्षित तरीका है “payment pending” रखना और स्पष्ट कस्टमर मैसेजिंग देना।

इच्छा से रिकवरी का परीक्षण करें। फेल्योर फोर्स करें, ब्रेकर खुलता देखें, कूलडाउन के जरिए प्रतीक्षा करें, और पुष्टि करें कि Half‑open केवल छोटे probes भेजता है। अगर वह सफल हो तो जल्दी बंद होना चाहिए; अगर विफल हो तो बिना वेंडर को फ्लड किए फिर से खुल जाना चाहिए।

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

अगले कदम: AppMaster में पैटर्न लागू करना

ऐसा एक इंटीग्रेशन चुनें जो फेल होने पर दैनिक संचालन को प्रभावित कर सकता है (पेमेंट्स, शिपिंग लेबल्स, SMS, CRM सिंक)। पहले उसी एक कॉल के लिए ब्रेकर end‑to‑end बनाएं। जब टीम व्यवहार पर भरोसा करने लगे तो उसी टेम्पलेट को अगले वेंडर के लिए दोहराएँ।

AppMaster में ब्रेकर स्टेट को PostgreSQL में Data Designer के ज़रिए मॉडल करें। सरल रखें: प्रति वेंडर (या एंडपॉइंट) एक रिकॉर्ड जिसमें फील्ड्स जैसे state, failure_count, last_failure_at, open_until, और छोटा last_error हो।

फिर Business Process Editor में लॉजिक लागू करें और पढ़ने में आसान ब्रांच बनाएं। स्पष्टता चालाकी से बेहतर है।

व्यवहारिक बिल्ड ऑर्डर:

1. ब्रेकर स्टेट चेक करें और जब open_until भविष्य में हो तो कॉल ब्लॉक करें।
2. वेंडर API कॉल करें और सफलता तथा एरर आउटपुट कैप्चर करें।
3. सफलता पर काउंटर रीसेट करें और ब्रेकर बंद कर दें।
4. विफलता पर काउंटर बढ़ाएँ और थ्रेशहोल्ड मिलने पर ब्रेकर खोलें।
5. यूजर‑फेसिंग फ्लोज़ को फॉलबैक पर रूट करें (वर्क कतारबद्ध करें, कैश्ड डेटा उपयोग करें, या मैन्युअल प्रोसेस की अनुमति दें)।

सपोर्ट और ऑप्स को दिखाने के लिए फॉलबैक निर्णय को साधारण भाषा में डॉक्यूमेंट करें ताकि वे जानें उपयोगकर्ता को क्या दिखेगा।

जब ब्रेकर खुले, तो AppMaster के मेसेजिंग मॉड्यूल्स (ईमेल, SMS, Telegram) का उपयोग कर एक ओनर को नोटिफाई करें। जो चीज़ें मायने रखती हैं उन्हें शामिल करें: वेंडर, एंडपॉइंट, स्टेट, और पहला सुझाया कदम।

यदि आप ये वर्कफ़्लोज़ AppMaster में बना रहे हैं तो appmaster.io एक व्यावहारिक जगह है शुरू करने के लिए क्योंकि वही विज़ुअल Business Process एंडपॉइंट्स, बैकग्राउंड जॉब्स, और अलर्टिंग को एक साझा ब्रेकर स्टेट के साथ पावर कर सकता है।