ভিজ্যুয়াল ওয়ার্কফ্লোতে তৃতীয় পক্ষের API-এর জন্য সার্কিট ব্রেকার প্যাটার্ন

কেন তৃতীয় পক্ষের API আউটেজ কয়েকটি ফিচারই ভঙ্গ করে না\n\nএকটি তৃতীয় পক্ষের API প্রায়ই দৈনন্দিন কাজের মাঝখানে থাকে: পেমেন্ট গ্রহণ করা, ঠিকানা যাচাই করা, ইনভেন্টরি সিঙ্ক করা, মেসেজ পাঠানো, পরিচয় যাচাই করা। যখন সেই ভেন্ডরের সমস্যা হয়, তা সাধারণত কেবল একটি বোতামই ভেঙে ফেলে না। পুরো ফ্লো থেমে যেতে পারে যেগুলো সেই উত্তর ছাড়া এগোতে পারে না।\n\nএই কারণেই সার্কিট ব্রেকার গুরুত্বপূর্ণ। এটা কোনো তত্ত্ব নয়—এটি একটি ব্যবহারিক উপায় যাতে ইন্টিগ্রেশন অস্বস্থির হলেও মূল অপারেশন চালিয়ে রাখা যায়।\n\nধীরতা এবং ডাউন হওয়া আলাদা ভাবে ক্ষতিগ্রস্ত করে।\n\nযখন একটি API ধীরে চলে, আপনার ওয়ার্কফ্লো এখনও সফল হওয়ার চেষ্টা করে, কিন্তু প্রতিটি ধাপ অপেক্ষা করে। ব্যবহারকারীরা লোডিং দেখেন, সাপোর্ট টিম পায় "এটা আটকে আছে" ধরনের টিকিট, এবং ব্যাকগ্রাউন্ড জব জমতে শুরু করে। ধীরতা ঝুঁকিপূর্ণ কারণ এটা আপনার নিজের সিস্টেমের ত্রুটি মনে হতে পারে।\n\nযখন একটি API পুরোপুরি নামছে, আপনি টাইমআউট বা হার্ড এরর পান। এটা অনেকক্ষেত্রে স্পষ্ট, কিন্তু বেশি বিপজ্জনকও হতে পারে কারণ ওয়ার্কফ্লো সাধারণত পুনরায়চেষ্টা করে। যখন অনেক অনুরোধ একই সময়ে পুনরায়চেষ্টা করে, আপনি একটি ট্র্যাফিক ঝাঁকুনি তৈরি করেন যা পুনরুদ্ধার কঠিন করে এবং আপনার নিজের সিস্টেমকেও ধাক্কা দিতে পারে।\n\nসাধারণ লক্ষণ দ্রুত দেখা যায়: টাইমআউট, বাড়তে থাকা কিউ, আংশিক আপডেট এবং অনেক ম্যানুয়াল ক্লিনআপ।\n\nবাস্তব ক্ষতি হল চেইন রিএকশন। যদি একটি শিপিং-রেট প্রোভাইডার ধীরে চলে, অর্ডার প্লেসমেন্ট ধীর হয়ে যায় কারণ ওয়ার্কফ্লো কোট ছাড়া অর্ডার কনফার্ম করতে মানা করে। যদি পেমেন্ট ডাউন থাকে, সাপোর্ট রিফান্ড ইস্যু করতে ব্যর্থ হতে পারে যদিও বাকি সব ঠিকঠাক চলে।\n\nআপনি আউটেজ অদৃশ্য করে দিতে পারবেন না। লক্ষ্য হল ওয়ার্কফ্লো এমনভাবে ডিজাইন করা যাতে স্পষ্ট ফালব্যাক পথ, অস্থায়ী ব্লকিং নিয়ম, এবং সতর্কতা থাকে যাতে ব্যবসা অর্ডার নিতে, গ্রাহক সেবা চালাতে এবং কাজ রেকর্ড করতে পারে যখন ইন্টিগ্রেশন ঠিক হয়ে আসে।\n\n## সার্কিট ব্রেকার সহজ ভাষায়\n\nসার্কিট ব্রেকার হচ্ছে API কলগুলোর জন্য একটি সেফটি সুইচ। যখন একটি তৃতীয়-পক্ষের সার্ভিস ব্যর্থ হতে শুরু করে, ব্রেকার আপনার ওয়ার্কফ্লোকে বারবার সেটি চাপা বন্ধ করে দেয়। একটিবারের আউটেজকে ধীর স্ক্রিন, টাইমআউট এবং আটকে থাকা জব-এ রূপান্তর করার পরিবর্তে আপনি বিস্তৃত প্রভাব নিয়ন্ত্রণ করেন।\n\nএকটি সার্কিট ব্রেকারে তিনটি সহজ ফলাফল থাকে:\n\n- কল অনুমোদন করুন যখন ভেন্ডর স্বাস্থ্যবান থাকে।\n- কল ব্লক করুন যখন ব্যর্থতা উচ্চ এবং মুহূর্তের মধ্যে একটি ফালব্যাক নিন।\n- ছোট একটি টেস্ট কল চেষ্টা করুন সংক্ষিপ্ত বিরতির পরে দেখতে যে ভেন্ডর ফিরে এসেছে কি না।\n\nআপনি যদি লেবেল পছন্দ করেন, সেগুলো হল “closed,” “open,” এবং “half-open।” নামগুলোই মূল বিষয় নয়—পূর্বানুমেয়তা গুরুত্বপূর্ণ। যখন ভেন্ডর অসুস্থ, আপনার ওয়ার্কফ্লো প্রতিবার একইভাবে আচরণ করা উচিত।\n\nএটি ত্রুটিগুলো লুকায় না। আপনি এখনও ব্যর্থতা রেকর্ড করবেন, ব্যবহারকারী বা অপস-কে স্পষ্ট স্ট্যাটাস দেখাবেন, এবং সঠিক লোকদের সতর্ক করবেন। আপনি দ্রুত ব্যর্থ হওয়ার, কাজকে একটি নিরাপদ বিকল্পে রুট করার, বা আবার টেস্ট করার আগে সামান্য বিরতি নেওয়ার সিদ্ধান্ত নিচ্ছেন।\n\n## কোন API কলগুলো ব্যবসা কখনও থামতে দেয় না তা চয়ন করুন\n\nসার্কিট ব্রেকার সবচেয়ে ভাল কাজ করে যখন আপনি নির্বাচনী হন। প্রতিটি ভেন্ডর কলকে বিশেষ সুরক্ষা দেওয়ার দরকার নেই। শুরু করা উচিত এমন ধাপগুলো থেকে যেগুলো ব্লক হলে টাকা, অর্ডার, বা গ্রাহক অ্যাক্সেস থেমে যায়।\n\nএকটি ব্যবহারিক পদ্ধতি হল একটি ব্যবহারকারীর অনুরোধ পুরোভাবে অনুসরণ করা। কোথায় একটি টাইমআউট ব্যবহারকারীকে কাজ ত্যাগ করতে বাধ্য করবে, বা এমন বিশৃঙ্খলা তৈরি করবে যা আপনার টীম পরে পরিষ্কার করতে হবে?\n\nসাধারণ "কোর কাজ ব্লক করলে চলবে না" কলগুলোর মধ্যে আছে: পেমেন্ট, শিপিং ও ফুলফিলমেন্ট, লগইন/SSO/MFA, OTP ও কনফার্মেশন মেসেজ, এবং অনুমোদনের সাথে যুক্ত কমপ্লায়েন্স চেক।\n\nএছাড়াও ব্যবহারকারী-ফেসিং ধাপগুলোকে ব্যাকগ্রাউন্ড জব থেকে আলাদা করুন। কেউ যদি চেকআউট স্ক্রিনে অপেক্ষা করে থাকে, আপনাকে দ্রুত সিদ্ধান্ত নিতে হবে: সফল, ফালব্যাক, বা পরিষ্কার বার্তা দিয়ে বন্ধ। ব্যাকগ্রাউন্ড কাজের জন্য যেমন ট্র্যাকিং নম্বর সিঙ্ক, ধীরে পুনরায়চেষ্টা ঠিক আছে যতক্ষণ সেটা প্রধান ফ্লো ব্লক না করে।\n\nদায়িত্ব বাড়তে না দেওয়ার জন্য প্রথমে ছোট শুরু করুন। প্রথমে 1–3টি ওয়ার্কফ্লো সুরক্ষিত করুন, তারপর বিস্তৃত করুন।\n\nকিছু তৈরি করার আগে “নিরাপদ ফালব্যাক” এর অর্থ সংজ্ঞায়িত করুন। ভাল ফালব্য্যাক নির্দিষ্ট এবং পরীক্ষা যোগ্য:\n\n- পেমেন্ট: অর্ডারকে “payment pending” হিসেবে সংরক্ষণ করুন যাতে কার্ট হারিয়ে না যায়।\n- শিপিং: ক্যাশ করা রেট, একটি ফ্ল্যাট রেট, বা লেবেল ক্রয় পরবর্তী সময়ে দেরি করে কনফার্ম করুন।\n- পরিচয়: SSO ডাউন হলে পাসওয়ার্ড লগইন অনুমোদন করুন, অথবা ইমেল যাচাইকরণে স্যুইচ করুন।\n- মেসেজিং: SMS পরে পাঠানোর জন্য কিউ করুন এবং যেখানে সম্ভব বিকল্প পথ দিন।\n\nAppMaster-এর Business Process Editor-এ এটি সাধারণত একটি পরিষ্কার ব্রাঞ্চ হয়ে ওঠে: কোর অপারেশন চলতে থাকে, আর ভেন্ডর-নির্ভর ধাপ একটি নিয়ন্ত্রিত বিকল্প নেয়।\n\n## রাজ্য, থ্রেশহোল্ড, এবং টাইমারগুলো যা আপনি ব্যাখ্যা করতে পারেন\n\nসার্কিট ব্রেকার একটি সেফটি সুইচ। বেশিরভাগ সময় এটি কলগুলোকে অনুমতি দেয়। যখন ভেন্ডর ব্যর্থ হতে শুরু করে, এটি আপনার ওয়ার্কফ্লোকে সময় ও ত্রুটি-সমৃদ্ধির হাত থেকে রক্ষা করতে ফ্লিপ করে।\n\n### তিনটি রাজ্য\n\nClosed স্বাভাবিক। আপনি API কল করেন এবং এগিয়ে যান।\n\nযদি ব্যর্থতা একটি সীমা ছাড়িয়ে যায়, ব্রেকার Open হয়। আপনি সংক্ষিপ্ত সময়ের জন্য ভেন্ডরকে কল করা বন্ধ করেন এবং ফালব্যাকে রুট করেন (ক্যাশ করা মান, কিউ করা কাজ, বিকল্প ফ্লো)।\n\nকুলডাউন পরে ব্রেকার Half-open হয়। আপনি কিছু সীমিত টেস্ট কল অনুমোদন করেন। সেগুলো সফল হলে আপনি Closed-এ ফিরে যান। ব্যর্থ হলে আবার Open-এ যান।\n\n### কী মাপবেন\n\nভেন্ডর কীভাবে ব্যর্থ করে তার সাথে মিলবে এমন সিগন্যাল ব্যবহার করুন:\n\n- টাইমআউট\n- HTTP 5xx এরর\n- বৃদ্ধিপ্রাপ্ত লেটেন্সি (অকার্যকরভাবে ধীর)\n- কানেকশন/DNS ত্রুটি\n- 429 রেট লিমিট\n\nএকটি ভিজ্যুয়াল ওয়ার্কফ্লো টুলে এগুলো সাধারণত সহজ চেকে ম্যাপ হয়: স্ট্যাটাস কোড, অতিবাহিত সময়, এবং নির্দিষ্ট এরর আউটপুট।\n\n### শুরু করা থ্রেশহোল্ড এবং দুটি প্রধান টাইমার\n\nবোঝাতে সহজ এমন সংখ্যাগুলো দিয়ে শুরু করুন, তারপর বাস্তব ট্রাফিক অনুযায়ী টিউন করুন। উদাহরণ:\n\n- 30–60 সেকেন্ডের মধ্যে 5–10 কল ব্যর্থ হলে ব্রেকার Open করুন।\n- অথবা রোলিং উইন্ডোতে 20%–40% কল ব্যর্থ হলে Open করুন।\n- যেখানে প্রক্রিয়াটি সহ্য করতে পারবে না এমন লেটেন্সি (প্রায় 2–5 সেকেন্ড), সেটাকে ব্যর্থতা হিসেবে গণ্য করুন।\n\nতারপর দুইটি টাইমার সেট করুন:\n\n- Cooldown time (Open state): সাধারণত 30 সেকেন্ড থেকে 5 মিনিট।\n- Half-open test window: 1–5টি টেস্ট কল বা 10–30 সেকেন্ডের মতো সংক্ষিপ্ত উইন্ডো অনুমোদন করুন।\n\nউদ্দেশ্য সহজ: ভেন্ডর অসুস্থ হলে দ্রুত ব্যর্থ করুন, ভেন্ডর ফিরে এলে স্বয়ংক্রিয়ভাবে পুনরুদ্ধার করুন।\n\n## ধাপে ধাপে: একটি ভিজ্যুয়াল ওয়ার্কফ্লোতে সার্কিট ব্রেকার তৈরি করুন\n\nসর্বাপেক্ষা গুরুত্বপূর্ণ ডিজাইন সিদ্ধান্ত হল “এখন কি আমরা ভেন্ডরকে কল করব?” এই সিদ্ধান্তটিকে এক জায়গায় রাখুন, সব ওয়ার্কফ্লো জুড়ে ছড়িয়ে রাখবেন না।\n\n### 1) ভেন্ডর কলটি একটি পুনঃব্যবহারযোগ্য ব্লকের পেছনে রাখুন\n\nএকটি সাব-প্রসেস (একটি পুনরায়ব্যবহারযোগ্য ওয়ার্কফ্লো ব্লক) তৈরি করুন যা প্রতিটি ওয়ার্কফ্লো ব্যবহার করবে যখন সেটি ওই ভেন্ডরকে প্রয়োজন। AppMaster-এ এটা সহজেই একটি Business Process হিসেবে মানচিত্র করা যায় যা আপনি এন্ডপয়েন্ট বা অটোমেশন থেকে কল করবেন। সরল রাখুন: ইনপুট যায়, ভেন্ডর রিকোয়েস্ট যায়, এবং একটি স্পষ্ট success/fail ফলাফল আসছে।\n\n### 2) ফলাফলগুলো সময়সহ ট্র্যাক করুন, শুধু গণনা নয়\n\nপ্রতিটি আউটকাম একটি টাইমস্ট্যাম্পসহ রেকর্ড করুন। যেমন: last success, last failure, উইন্ডোর মধ্যে ব্যর্থতা সংখ্যা, বর্তমান স্টেট, এবং একটি cooldown deadline।\n\nএই ফিল্ডগুলো একটি টেবিলে স্থায়ী করুন যাতে ব্রেকার রিস্টার্টে টিকে থাকে এবং একাধিক ইনস্ট্যান্সে সঙ্গত থাকে। PostgreSQL via Data Designer এ এটি ভালভাবে ফিট হয়।\n\n### 3) প্রতিবার আপনি যে স্টেট পরিবর্তন অনুসরণ করবেন তা সংজ্ঞায়িত করুন\n\nনিয়মগুলো সহজ রাখুন। উদাহরণ: যদি 2 মিনিটের মধ্যে 5 ব্যর্থতা ঘটে, Open-এ স্যুইচ করুন। Open থাকা অবস্থায় ভেন্ডর কল বাদ দিন যতক্ষণ না কুলডাউন পাস করে। কুলডাউন পরে Half-open যান এবং একটি নিয়ন্ত্রিত চেষ্টা অনুমোদন করুন। যদি সেটি সফল হয়, ব্রেকার বন্ধ করুন। ব্যর্থ হলে আবার Open করুন।\n\n### 4) ওয়ার্কফ্লো ব্রাঞ্চ করুন: ভেন্ডর পথ বনাম ফালব্যাক পথ\n\nভেন্ডর রিকোয়েস্টের আগে স্টোর করা স্টেট চেক করুন:\n\n- Closed: ভেন্ডর কল করুন, তারপর success অথবা failure আপডেট করুন।\n- Open: কল বাদ দিন এবং fallback চালান।\n- Half-open: সীমিত একটি চেষ্টা অনুমোদন করুন, তারপর close না open তা নির্ণয় করুন।\n\nউদাহরণ: যদি একটি শিপিং লেবেল API ডাউন থাকে, ফালব্যাক অর্ডার তৈরি করতে পারে Label pending স্ট্যাটাস দিয়ে এবং একটি রিট্রাই জব কিউ করতে পারে, চেকআউট বা ওয়ারহাউস কাজ ব্লক না করে।\n\n### 5) একাধিক ওয়ার্কফ্লো জুড়ে শেয়ার করুন\n\nযদি আপনার একাধিক ওয়ার্কফ্লো এবং সার্ভার থাকে, তাদের একই ব্রেকার স্টেট পড়া ও লেখা দরকার। নাহলে একটি ইনস্ট্যান্স ভেন্ডরকে বারংবার হ্যামার করতে পারে যতক্ষণ না অন্যটি সিদ্ধান্ত নিয়েছে বিরতি নেওয়াটা ভাল।\n\n## কাজ চালিয়ে রাখার জন্য ফালব্যাক পথগুলো\n\nএকটি সার্কিট ব্রেকার শুধুমাত্র সহায়ক যদি আপনি নির্ধারণ করেন কী হবে যখন কল ব্লক করা হবে। একটি ভাল ফালব্যাক ব্যবহারকারীকে এগোতে দিতে হবে, আপনার ডেটা রক্ষিত রাখতে হবে, এবং পরে ক্লিনআপ সহজ করে তুলবে।\n\nকাজ অনুযায়ী একটি ফালব্যাক বেছে নিন। যদি একটি শিপিং-রেট প্রোভাইডার ডাউন থাকে, হয়তো সঠিক মূল্য ছাড়া অর্ডার গ্রহণ করা লাগবে না। একটি ভিজ্যুয়াল ওয়ার্কফ্লো-এ ব্যর্থ API স্টেপকে এমন একটি ফালব্য্যাক ব্রাঞ্চে রুটি করুন যা এখনও ব্যবহারযোগ্য আউটকাম দেয়।\n\nবাস্তবে, ফালব্যাকগুলো সাধারণত এরকম দেখায়:\n\n- একটি ক্যাশ করা শেষ-জানা মান ব্যবহার (স্পষ্ট freshness উইন্ডো সহ)।\n- নিরাপদ ডিফল্ট অনুমান ব্যবহার, স্পষ্টভাবে লেবেল করা।\n- ম্যানুয়াল রিভিউ-এ রুট করা।\n- কাজ পরে রিটারাই করার জন্য কিউ করা (অ্যাসিংক জব)।\n\nব্যবহারকারীর অভিজ্ঞতাও লজিকের মত গুরুত্বপূর্ণ। একটি অস্পষ্ট এরর দেখাবেন না। বলুন কী হয়েছে এবং ব্যবহারকারী পরবর্তী কী করতে পারে: “আমরা এখন রেট নিশ্চিত করতে পারিনি। আপনি একটি আনুমানিক শিপিং খরচ দিয়ে অর্ডার করতে পারেন, অথবা এটি রিভিউ করার জন্য সংরক্ষণ করুন।”\n\nসংক্ষিপ্ত বনাম দীর্ঘ আউটেজ-planning করাও প্রয়োজন। একটি সংক্ষিপ্ত আউটেজ (মিনিট) সাধারণত মানে “চলতে থাকুন, ব্যাকগ্রাউন্ডে রিটারাই করুন।” একটি দীর্ঘ আউটেজ (ঘন্টা) বেশি কঠোর নীতি প্রয়োজন করতে পারে—যেমন বেশি ম্যানুয়াল রিভিউ বা অনুমোদন।\n\nঅবশেষে, প্রতিটি ফালব্যাক ট্র্যাক করুন যাতে রিকনসিলিয়েশন সহজ হয়। অন্তত, ফালব্যাক টাইপ, মূল অনুরোধের বিবরণ, ব্যবহারকারীর কাছে কী ফেরত দেওয়া হয়েছে (এবং সেটি আনুমানিক ছিল কি না), এবং ফলো-আপের স্ট্যাটাস রেকর্ড করুন।\n\n## অস্থায়ী ব্লকিং নিয়ম এবং স্মার্ট রিট্রাই\n\nনিয়ন্ত্রিত না রাখা পুনরায়চেষ্টা ছোট ভেন্ডর হিকআপকে বাস্তব আউটেজে পরিণত করে। যখন অনেক ওয়ার্কফ্লো একই সময়ে পুনরায়চেষ্টা করে, তারা একটি স্পাইক ("thundering herd") তৈরি করে। ভেন্ডর ধীর হয়ে যায়, আপনার কিউ জমে যায়, এবং রেট লিমিট পুড়ে যায়।\n\nরিট্রাইগুলো পূর্বানুমেয় এবং সীমিত হওয়া উচিত, এবং ব্রেকার স্টেটকে সম্মান করা উচিত। একটি ব্যবহারিক নীতি হচ্ছে:\n\n- সর্বোচ্চ রিট্রাই কম রাখুন (সাধারণত 2–3)।\n- এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করুন (উদাহরণ: 2s, 8s, 30s)।\n- জিটার যোগ করুন যাতে সব রিট্রাই সিঙ্ক না হয়।\n- মোট রিট্রাই সময়কে সীমাবদ্ধ করুন (উদাহরণ: 60–90 সেকেন্ড)।\n- যদি ব্রেকার Open থাকে, রিট্রাই করবেন না—সোজা ফালব্যাকে যান।\n\nঅস্থায়ী ব্লকিং সম্পর্কিত কিন্তু পৃথক: এটি সেই কেসগুলোর জন্য যেখানে রেসপন্স আপনাকে বলে “এটি এখন কাজ করবে না।” সাধারণ নিয়ম:\n\n- 429 rate limit: Retry-After পিরিয়ডের জন্য ব্লক করুন (বা নিরাপদ নির্দিষ্ট উইন্ডো)।\n- 401/403 auth failure: ক্রেডেনশিয়াল রিফ্রেশ না হওয়া পর্যন্ত ব্লক করুন, তারপর একবার টেস্ট করুন।\n- সতত 5xx: সংক্ষেপে ব্লক করুন, তারপর ছোট একটি টেস্ট অনুমোদন করুন।\n\nব্লকের সময়, চলতি কাজগুলোর কী হবে তা নির্ধারণ করুন: কিউ করা, reroute করা, বা graceful degrade (উদাহরণ: অর্ডার গ্রহণ কিন্তু “send SMS” দেরি করা)।\n\n## কীভাবে সতর্কতা দিন যাতে একশন স্পষ্ট হয়\n\nসার্কিট ব্রেকার কেবল তখনই সহায়ক যখন মানুষ দ্রুত জানে এবং কী করা উচিত তা জানে। লক্ষ্য নয় শব্দবাজি—লক্ষ্য হল এক স্পষ্ট বার্তা যখন আচরণ বদলায়: কল ব্লক হচ্ছে, ফালব্যাক সক্রিয়, বা ব্রেকার আশা করার চেয়ে বেশি সময় Open থাকে।\n\nভাল ডিফল্ট ট্রিগারগুলো:\n\n- ব্রেকার Open হলে সতর্কতা দিন।\n- যদি এটি নির্দিষ্ট সময়ের বেশি Open থাকে, সতর্কতা দিন।\n- Open হওয়ার আগেই ত্রুটির তীব্র বৃদ্ধি থাকলে সতর্কতা দিন।\n\nসতর্কতিগুলো কার্যকর হতে হবে। ভেন্ডর ও এন্ডপয়েন্ট, বর্তমান স্টেট ও কখন বদলেছে, ব্যবহারকারীরা কী অনুভব করবে, ওয়ার্কফ্লো এখন কী করছে (ব্লক, রিট্রাই, ফালব্যাক), এবং এক সুপারিশকৃত পরবর্তী ধাপ অন্তর্ভুক্ত করুন।\n\nগুরুত্ব অনুসারে সতর্কতা রুট করুন। একটি নন-ক্রিটিকাল এনরিচমেন্ট API ইমেইলে যেতে পারে। পেমেন্ট, লগইন, বা অর্ডার সাবমিশন সাধারণত পেজ যোগ্য। AppMaster-এ এটি সহজেই এমন ব্রাঞ্চে মানচিত্র হয় যা severity ফ্ল্যাগ অনুযায়ী ইমেইল, Telegram, বা SMS পাঠায়।\n\nকয়েকটি মেট্রিক ট্র্যাক করুন যাতে দেখা যায় আপনি পুনরুদ্ধার করছেন কি না: ভেন্ডর অনুযায়ী ব্লক করা কল এবং ফালব্যাক ব্যবহার প্রায়ই যথেষ্ট।\n\n## উদাহরণ ঘটনা: ভেন্ডর আউটেজ থাকা সত্ত্বেও অর্ডার থামছে না\n\nএকটি সাধারণ ব্যর্থতা: গ্রাহকরা চেকআউট করে এমন সময় আপনার শিপিং রেট প্রোভাইডার ডাউন হয়ে যায়। যদি আপনার ওয়ার্কফ্লো অর্ডার তৈরির সময় লাইভ রেটগুলোর ওপরই নির্ভর করে, একটি সিঙ্গেল আউটেজ সম্পূর্ণ অর্ডারকে থামিয়ে দিতে পারে।\n\nস্বাভাবিক দিনে, অর্ডার তৈরি হয়, তারপর ওয়ার্কফ্লো লাইভ রেট অনুরোধ করে, এবং অর্ডার নির্বাচিত ক্যারিয়ার ও মূল্যের সঙ্গে সেভ হয়।\n\nযখন ভেন্ডর ব্যর্থ হতে শুরু করে, কলগুলো টাইমআউট বা 5xx রিটার্ন করে। আপনার থ্রেশহোল্ড পৌঁছালে (উদাহরণ: 2 মিনিটে 5 ব্যর্থতা), ব্রেকার Open হয়।\n\nOpen থাকা অবস্থায়, ওয়ার্কফ্লো সংক্ষিপ্ত উইন্ডো (উদাহরণ: 10 মিনিট) ধরে শিপিং প্রোভাইডারকে কল করা বন্ধ করে। এটি ব্যর্থ ভেন্ডরকে সবার জন্য চেকআউট ধীর করার থেকে রোধ করে।\n\nচেকআউট ব্লক করার পরিবর্তে, ফালব্যাক করতে পারে:\n\n- একটি ফ্ল্যাট-রেট প্রয়োগ করা (বা একটি নিরাপদ অনুমান)।\n- তবুও অর্ডার তৈরি করা।\n- এটি “Shipping rate pending” হিসেবে চিহ্নিত করা পরে পুনরায় গণনার জন্য।\n- ভেন্ডরের এরর ডিটেইল সংরক্ষণ করা ফলো-আপের জন্য।\n\nAppMaster-এ এটি Business Process Editor-এ একটি পরিষ্কার ব্রাঞ্চ যা Data Designer ফিল্ড যেমন shipping_rate_status এবং shipping_rate_source—এর মাধ্যমে ব্যাক করা থাকে।\n\n## প্রকাশের আগে দ্রুত চেক তালিকা\n\nএকটি সার্কিট ব্রেকার চাপের মধ্যে একইভাবে আচরণ করা উচিত যেমন ডেমো-তে করে। রিলিজের আগে মৌলিক বিষয়গুলো নিশ্চিত করুন:\n\n- থ্রেশহোল্ড এবং কুলডাউন ডকুমেন্টেড এবং সহজে পরিবর্তনযোগ্য।\n- Open স্টেট কলগুলো অবিলম্বে ব্লক করে (ভেন্ডর টাইমআউটের অপেক্ষা না করে)।\n- ফালব্যাক আচরণ অর্থ এবং গ্রাহক প্রতিশ্রুতি জন্য নিরাপদ।\n- Half-open probing সীমিত কয়েকটি টেস্ট কলের মধ্যে।\n- লগিং টাইমিং এবং প্রভাব দ্রুত বোঝার মত।\n\nফালব্যাক সেফটিতে অতিরিক্ত সময় ব্যয় করুন। “কাজ চালিয়ে রাখে” এমন একটি ফালব্যাক আর্থিক ঝুঁকি তৈরি করতে পারে। যদি পেমেন্ট প্রোভাইডার ডাউন, অর্ডারকে paid হিসেবে চিহ্নিত করা বিপজ্জনক। সুরক্ষিত পন্থা হচ্ছে “pending payment” এবং স্পষ্ট গ্রাহক মেসেজিং।\n\nঅজাচ্ছন্দ্য করে পুনরুদ্ধার পরীক্ষা করুন। ইচ্ছাকৃতভাবে ব্যর্থতা জেনারেট করুন, ব্রেকার Open হওয়া দেখুন, কুলডাউন শেষে Half-open নিশ্চিত করুন যে কেবল ছোট একটি probe পাঠায়। যদি সফল হয়, দ্রুত Close হওয়া উচিত। ব্যর্থ হলে পুনরায় Open হওয়া উচিত এবং ভেন্ডরকে ভরাট না করা উচিত।\n\nআপনার লগগুলোর উত্তর থাকা উচিত এক মিনিটের মধ্যে: কে প্রভাবিত হয়েছে, কখন শুরু হয়েছে, কোন ওয়ার্কফ্লো স্টেপ ব্রেকার ট্রিগার করেছে, এবং কোন ফালব্যাক ব্যবহার করা হয়েছে।\n\n## পরবর্তী ধাপ: AppMaster-এ প্যাটার্নটি বাস্তবায়ন\n\nএকটি ইন্টিগ্রেশন বেছে নিন যা ব্যর্থ হলে দৈনন্দিন অপারেশন ক্ষতিগ্রস্ত করে (পেমেন্ট, শিপিং লেবেল, SMS, CRM সিঙ্ক)। প্রথমে ঐ সিঙ্গেল কলের জন্য ব্রেকার পুরোপুরি তৈরি করুন। টীম যখন আচরণে বিশ্বাস পাবে, একই টেমপ্লেট পরবর্তী ভেন্ডরের জন্য পুনরায় ব্যবহার করুন।\n\nAppMaster-এ, Data Designer ব্যবহার করে PostgreSQL-এ ব্রেকার স্টেট মডেল করুন। সরল রাখুন: প্রতিটি ভেন্ডর (বা এন্ডপয়েন্ট) জন্য একটি রেকর্ড—with fields like state, failure_count, last_failure_at, open_until, and a short last_error.\n\nতারপর Business Process Editor-এ লজিক বাস্তবায়ন করুন সহজ পাঠযোগ্য ব্রাঞ্চের সঙ্গে। স্পষ্টতা জটিলতাকে হারায়।\n\nএকটি ব্যবহারিক বিল্ড অর্ডার:\n\n1. ব্রেকার স্টেট চেক করুন এবং open_until ভবিষ্যতে থাকলে কল ব্লক করুন।\n2. ভেন্ডর API কল করুন এবং success ও error আউটপুট ক্যাপচার করুন।\n3. সাফল্যে কাউন্টার রিসেট করুন এবং ব্রেকার বন্ধ করুন।\n4. ব্যর্থ হলে কাউন্টার বাড়ান এবং থ্রেশহোল্ড পেলে ব্রেকার Open করুন।\n5. ব্যবহারকারী-ফেসিং ফ্লোকে ফালব্যাক রুট করুন (কিউ করুন, ক্যাশ করা ডেটা ব্যবহার করুন, বা ম্যানুয়াল প্রসেসিং অনুমোদন করুন)।\n\nফালব্যাক সিদ্ধান্ত সাপোর্ট ও অপস বোঝার সুবিধার্থে সরল ভাষায় ডকুমেন্ট করুন।\n\nব্রেকার Open হলে, AppMaster ম্যাসেজিং মডিউল ব্যবহার করে (ইমেইল, SMS, Telegram) একজন মালিককে নোটিফাই করুন। গুরুত্বপূর্ণ তথ্য দিন: ভেন্ডর, এন্ডপয়েন্ট, স্টেট, এবং প্রথম সুপারিশকৃত অ্যাকশন।\n\nযদি আপনি এই ওয়ার্কফ্লোগুলো AppMaster-এ তৈরি করছেন, appmaster.io হচ্ছে একটি ব্যবহারিক শুরু করার জায়গা কারণ একই ভিজ্যুয়াল Business Process এন্ডপয়েন্ট, ব্যাকগ্রাউন্ড জব, এবং সতর্কতা সব এক শেয়ার্ড ব্রেকার স্টেট দিয়ে চালাতে পারে।