তৃতীয়‑পক্ষের API ইন্টিগ্রেশন নিরাপদভাবে: পুনরায় চেষ্টা, টাইমআউট, সার্কিট ব্রেকার

কেন তৃতীয়‑পক্ষের API আপনার মূল ওয়ার্কফ্লো আটকে দিতে পারে

একটি তৃতীয়‑পক্ষের API এমনভাবে ব্যর্থ হতে পারে যা স্পষ্ট "ডাউন" ঘটনার মতো নয়। সবচেয়ে সাধারণ সমস্যা হলো ধীরতা: অনুরোধ আটকে যায়, উত্তর দেরিতে আসে, আর আপনার অ্যাপ অপেক্ষা করতে থাকে। যদি এই কলগুলো ক্রিটিক্যাল পথের ওপর থাকে, বাহিরের একটি ছোট সমস্যা সিস্টেমের ভিতরে জমে যায়।

এভাবেই একটি লোকাল স্লোডাউন পুরো আউটেজে পরিণত হয়। থ্রেড বা ওয়ার্কাররা অপেক্ষায় আটকে যায়, কিউ বাড়ে, ডাটাবেস ট্রানজ্যাকশন দীর্ঘ সময় খোলা থাকে, এবং নতুন অনুরোধগুলো টাইমআউট করতে শুরু করে। খুব দ্রুত, এমনকি এমন পেজগুলোও ভাঙা লাগে যেগুলো এক্সটারনাল API ব্যবহার করে না, কারণ সিস্টেম অপেক্ষার কাজগুলোতে ওভারলোড হয়েছে।

প্রভাব বাস্তবজীবনভিত্তিক। একটি খারাপ পরিচয় প্রদানকারী সাইনআপ ও লগইন ব্লক করে। একটি পেমেন্ট গেটওয়ে টাইমআউট চেকআউট আটকে দেয়, ব্যবহারকারী নিশ্চিত না থাকে তারা চার্জ হয়েছে কিনা। মেসেজিং‑এ বিলম্ব পাসওয়ার্ড রিসেট ও অর্ডার কনফার্মেশন থামিয়ে দেয়, ফলে রিট্রাই এবং সাপোর্ট টিকিটের দ্বিতীয় ঢেউ আসে।

লক্ষ্য সহজ: বাহ্যিক ব্যর্থতাকে বিচ্ছিন্ন করা যাতে মূল ওয়ার্কফ্লো চলতেই থাকে। এর মানে হতে পারে ব্যবহারকারী অর্ডার প্লেস করতে পারে আর পরে পেমেন্ট নিশ্চিত করা হবে, বা স্বাগত ইমেইল ব্যর্থ হলে সাইনআপ অনুমতি দেওয়া।

একটি ব্যবহারিক সফলতার মেট্রিক: যখন কোনো প্রোভাইডার ধীর বা ডাউন হয়, আপনার অ্যাপ দ্রুত এবং পরিষ্কারভাবে রেসপন্ড করা উচিত, এবং বিস্তার সীমিত থাকা উচিত। উদাহরণস্বরূপ, বেশিরভাগ মূল অনুরোধ আপনার সাধারণ লেটেন্সি বাজেটের মধ্যে শেষ হয়, ব্যর্থতাগুলো শুধু নির্দিষ্ট ফিচারগুলোর মধ্যে থাকে, ব্যবহারকারীকে স্পষ্ট স্ট্যাটাস দেখানো হয় (queued, pending, try again later), এবং প্রোভাইডার ফিরলে স্বয়ংক্রিয়ভাবে পুনরুদ্ধার ঘটে।

যে ব্যর্থতার মোডগুলো পরিকল্পনা করা উচিত

অধিকাংশ ব্যর্থতা পূর্বানুমেয়, যদিও সময় নয়। এগুলো আগে থেকে নাম দিলে আপনি সিদ্ধান্ত নিতে পারবেন কী রিট্রাই করবেন, কী বন্ধ করবেন, এবং ব্যবহারকারীকে কী দেখাবেন।

সাধারণ শ্রেণি‑সমূহ:

• লেটেন্সি স্পাইক (হঠাৎ অনুরোধ 10x ধীর হয়ে যাওয়া)
• অস্থায়ী সার্ভার বা নেটওয়ার্ক ত্রুটি (টাইমআউট, 502/503, কানেকশন রিসেট)
• রেট লিমিট ও কোটা শেষ হয়ে যাওয়া (429, দৈনিক ক্যাপ)
• অথ/পারমিশন সমস্যা (মেয়াদউত্তীর্ণ কী, প্রত্যাহার করা অ্যাক্সেস)
• খারাপ বা অবাক করা ডেটা (মিসিং ফিল্ড, ভুল ফর্ম্যাট, আংশিক রেসপন্স)

সব ত্রুটি একই জিনিস বোঝায় না। অস্থায়ী সমস্যাগুলো প্রায়ই রিট্রাই করার মতো কারণ পরের কল সফল হতে পারে (নেটওয়ার্ক ব্লিপ, টাইমআউট, 502/503, এবং কিছু 429 ব্যবস্থা করে অপেক্ষায় থাকলে)। স্থায়ী সমস্যাগুলো সাধারণত নিজে থেকে ঠিক হবে না (অবৈধ ক্রেডেনশিয়াল, ভুল এন্ডপয়েন্ট, খারাপ অনুরোধ, পারমিশন ডিনায়াল)।

সব ত্রুটিকে একইভাবে ট্রিট করলে একটি ছোট ইনসিডেন্ট বড় ডাউনটাইমে পরিণত হয়। স্থায়ী ব্যর্থতাগুলো পুনরায় চেষ্টা করলে সময় নষ্ট হয়, রেট লিমিট দ্রুত স্পর্শ করে, এবং ব্যাকলগ গড়ে ওঠে যা সবকিছু ধীর করে দেয়। কখনও‑কখনও অস্থায়ী ব্যর্থতাগুলো একেবারেই রিট্রাই না করলে ব্যবহারকারীকে একই কাজ আবার করাতে হয় এবং এমন কাজ হারিয়ে যায় যা একটু পরে সম্পন্ন হতে পারত।

যেসব ওয়ার্কফ্লোতে একটা বিরতি ভেঙে যাওয়ার মতো লাগে (চেকআউট, লগইন, পাসওয়ার্ড রিসেট, নোটিফিকেশন) সেখানে অতিরিক্ত মনোযোগ দিন। মার্কেটিং API‑তে দুই সেকেন্ডের স্পাইক বিরক্তিকর; পেমেন্ট অনুমোদনে দুই সেকেন্ডের স্পাইক রাজস্ব জিজ্ঞাসায় বাধা দেয়।

একটি সহজ পরীক্ষা: "এই কলটি ব্যবহারকারীর প্রধান কাজটি এখনই শেষ করার জন্য কি আবশ্যক?" যদি হ্যাঁ, তাহলে কঠোর টাইমআউট, সাবধান রিট্রাই, এবং স্পষ্ট ব্যর্থতা পথ দরকার। যদি না হয়, তাহলে এটি কিউতে সরান এবং অ্যাপটিকে প্রতিক্রিয়াশীল রাখুন।

টাইমআউট: একটি সীমা নির্ধারণ করুন এবং তা মেনে চলুন

টাইমআউট হল সর্বোচ্চ সময় আপনি অপেক্ষা করতে চান, তারপর বন্ধ করে এগিয়ে যাওয়া। একটি পরিষ্কার সীমা না থাকলে একজন ধীর প্রোভাইডার অনেক অপেক্ষমাণ অনুরোধ জমিয়ে দিতে পারে এবং গুরুত্বপূর্ণ কাজ আটকে যাবে।

দুটি ধরনের অপেক্ষা আলাদা করে নেওয়া সাহায্য করে:

• কানেক্ট টাইমআউট: সংযোগ স্থাপনের জন্য কতক্ষণ চেষ্টা করবেন।
• রিড টাইমআউট: সংযোগের পর রেসপন্স পাওয়ার জন্য কতক্ষণ অপেক্ষা করবেন।

সংখ্যা বেছে নেওয়া পারফেকশনের কথা নয়। এটি মানুষের ধৈর্য এবং আপনার ওয়ার্কফ্লো অনুযায়ী মিলানো।

• যদি ব্যবহারকারী একটি স্পিনার দেখছে, সাধারণত দ্রুত উত্তর এবং পরবর্তী স্পষ্ট ধাপ দরকার।
• যদি এটি ব্যাকগ্রাউন্ড জব (যেমন রাতভর ইনভয়েস সিঙ্ক), আপনি বেশি সময় দিতে পারেন, কিন্তু এখনও একটি সিলিং থাকা উচিত যাতে এটি অসীমভাবে আটকে না যায়।

টাইমআউট নির্বাচন করা একটি ব্যবহারিক উপায়: অভিজ্ঞতা থেকে উল্টোভাবে কাজ করুন:

• ব্যবহারকারী কতক্ষণ অপেক্ষা করতে পারে আগে আপনাকে স্পষ্ট মেসেজ দেখাতে হবে?
• যদি এই কল এখন ব্যর্থ হয়, আপনি কি পরে রিট্রাই করতে পারবেন বা কোনো ফলব্যাক ব্যবহার করতে পারবেন?
• পিক লোডে এগুলোর মধ্যে কতগুলো চলে?

ট্রেড‑অফ বাস্তব। খুব দীর্ঘ করলে আপনি থ্রেড, ওয়ার্কার ও ডেটাবেস কানেকশন জড়িয়ে ফেলেন। খুব সংক্ষিপ্ত করলে মিথ্যা ব্যর্থতা তৈরি করেন এবং অপ্রয়োজনীয় রিট্রাই ট্রিগার করেন।

রিট্রাই যা আউটেজকে খারাপ করে না

রিট্রাই সহায়ক যখন একটি ব্যর্থতা সম্ভবত অস্থায়ী: নেটওয়ার্ক ইস্যু, DNS হিচকচ, বা একবারের 500/502/503। এসব ক্ষেত্রে, দ্বিতীয় চেষ্টা সফল হতে পারে এবং ব্যবহারকারী কিছুই অনুভব করে না।

ঝুঁকি হলো রিট্রাই স্টর্ম। অনেক ক্লায়েন্ট একসাথে ব্যর্থ হলে এবং সবাই একসাথে রিট্রাই করলে তারা প্রোভাইডারকে (এবং আপনারই কাজ চালানো কর্মীদের) ওভারলোড করতে পারে। ব্যাকঅফ এবং জিটার সেটা প্রতিরোধ করে।

একটি রিট্রাই বাজেট আপনাকে সতর্ক রাখে। প্রচেষ্টা কম রাখুন এবং মোট সময় সীমা দিন যাতে মূল ওয়ার্কফ্লো অন্য কারও উপর অপেক্ষা না করে আটকে না যায়।

একটি নিরাপদ ডিফল্ট রিট্রাই রেসিপি

• সাধারণত কয়েকবারই রিট্রাই করুন (সাধারণত মোট 1‑3 চেষ্টায়, ফ্লো অনুযায়ী)।
• এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করুন (উদাহরণ: 200ms, 500ms, 1s) এবং র‍্যান্ডম জিটার যোগ করুন।
• রিট্রাইতে মোট ব্যয় করা সময়কে ক্যাপ করুন (ইউজার‑ফেসিং ফ্লোতে সাধারণত কয়েক সেকেন্ড)।
• সব চেষ্টার জন্য একটি করে অ্যাটেম্পট টাইমআউট ব্যবহার করুন, এক দীর্ঘ টাইমআউট নয়।

প্রেডিক্টেবল ক্লায়েন্ট ত্রুটি যেমন 400/422 ভ্যালিডেশন ইস্যু, 401/403 অথ সমস্যা, বা 404 পুনরায় চেষ্টা করবেন না—সেগুলো প্রায়ই আবারও ব্যর্থ হবে এবং শুধু লোড বাড়াবে।

আরও একটি গার্ডরেল: POST/PUT-এর মতো write অপারেশন কেবল তখনই রিট্রাই করুন যখন আইডেমপটেন্সি নিশ্চিত থাকে, না হলে ডাবল চার্জ বা ডুপ্লিকেট রেকর্ডের ঝুঁকি থাকে।

আইডেমপটেন্সি: বাস্তব ওয়ার্কফ্লোতে রিট্রাইকে নিরাপদ করুন

আইডেমপটেন্সি মানে একই অনুরোধটি দুইবার চালালেও শেষ ফলাফল একই থাকবে। এটি গুরুত্বপূর্ণ কারণ রিট্রাই স্বাভাবিক: নেটওয়ার্ক ড্রপ করে, সার্ভার রিস্টার্ট হয়, ক্লায়েন্ট টাইমআউট করে। আইডেমপটেন্সি না থাকলে একটি "সহায়ক" রিট্রাই ডুপ্লিকেট সৃষ্টি করে এবং বাস্তব আর্থিক সমস্যা হতে পারে।

চেকআউট কল্পনা করুন: পেমেন্ট API ধীর, আপনার অ্যাপ টাইমআউট করে, আপনি রিট্রাই করেন। যদি প্রথম কলটি সফল হয়ে থাকে, রিট্রাই দ্বিতীয় চার্জ তৈরি করতে পারে। একই ঝুঁকি অর্ডার তৈরি, সাবস্ক্রিপশন শুরু, ইমেইল/এসএমএস পাঠানো, রিফান্ড ইস্যু, বা সাপোর্ট টিকিট তৈরি করার ক্ষেত্রে দেখা যায়।

সমাধান: প্রতিটি "কিছু করা" কলের সাথে একটি আইডেমপটেন্সি কী (বা রিকোয়েস্ট আইডি) সংযুক্ত করুন। এটি ব্যবহারকারী ক্রিয়ার জন্য ইউনিক হওয়া উচিত, প্রতিটি চেষ্টা নয়। প্রোভাইডার (বা আপনার নিজস্ব সার্ভিস) সেই কী ব্যবহার করে ডুপ্লিকেট সনাক্ত করে একই আউটকাম ফিরিয়ে দেবে পরিবর্তে কাজটি আবার করে দেওয়ার।

আইডেমপটেন্সি কী‑কে একটি হেডার মনে করবেন না যা কেউ ভুলে যায়—এটাকে ডেটা মডেলের অংশ হিসেবে বিবেচনা করুন।

প্রোডাকশনে টিকে থাকা একটি প্যাটার্ন

যখন ব্যবহারকারী ক্রিয়া শুরু করে (উদাহরণ: Pay ক্লিক করলে) তখন একটি কী জেনারেট করুন এবং সেটা আপনার লোকাল রেকর্ডে স্টোর করুন।

প্রতিটি চেষ্টায়:

• একই কী পাঠান।
• প্রাপ্ত চূড়ান্ত ফলাফল (সফল রেসপন্স, ব্যর্থতা কোড, চার্জ ID) সংরক্ষণ করুন।
• যদি আপনার কাছে ইতিমধ্যে রেকর্ড করা আউটকাম থাকে, সেই আউটকাম ফিরিয়ে দিন পুনরায় কাজ করার পরিবর্তে।

আপনি যদি অভ্যন্তরীণ কলগুলোর "প্রোভাইডার" হন, সার্ভার‑সাইডে একই আচরণ প্রয়োগ করুন।

সার্কিট ব্রেকার: যখন API ব্যর্থ হচ্ছে তখন কল করা বন্ধ করুন

সার্কিট ব্রেকার একটি সেফটি সুইচ। যখন বাহ্যিক সার্ভিস ব্যর্থ হতে শুরু করে, আপনি কিছু সময়ের জন্য তাকে কল করা বন্ধ করেন, পরিবর্তে আরও অনুরোধ সার্ভিসকে ওভারলোড করবে বলে তা এড়ানো যায়।

সার্কিট ব্রেকারের সাধারণত তিনটি অবস্থা থাকে:

• Closed: অনুরোধ স্বাভাবিকভাবে যায়।
• Open: কুলডাউন উইন্ডোর জন্য কল ব্লক করা হয়।
• Half‑open: কুলডাউন শেষে সীমিত সংখ্যক টেস্ট কল সার্ভিস পুনরুদ্ধার হয়েছে কিনা পরীক্ষা করে।

যখন ব্রেকার খোলা থাকে, আপনার অ্যাপটিকে কিছু প্রত্যাশিত করা উচিত। উদাহরণ: সাইনআপ সময় যদি ঠিকানা ভেরিফিকেশন API ডাউন থাকে, ঠিকানাটি গ্রহণ করে পরে রিভিউর জন্য চিহ্নিত করুন। যদি একটি পেমেন্ট রিস্ক চেক ডাউন হয়, অর্ডার ম্যানুয়াল রিভিউতে রাখুন বা অস্থায়ীভাবে ঐ অপশন বন্ধ করে ব্যবহারকারীকে ব্যাখ্যা করুন।

থ্রেশহোল্ড বেছে নিন যা ব্যবহারকারীর প্রভাবের সাথে মেলে:

• ধারাবাহিক ত্রুটি (উদাহরণ: 5 বার ব্যর্থতা)
• সংক্ষিপ্ত জানালায় উচ্চ ব্যর্থতার হার
• অনেক ধীর রেসপন্স (টাইমআউট)
• নির্দিষ্ট স্ট্যাটাস কোড (যেমন পুনরাবৃত্ত 503)

কুলডাউন সংক্ষিপ্ত রাখুন (সেকেন্ড থেকে এক মিনিট) এবং হাফ‑ওপেন প্রোব সীমিত রাখুন। লক্ষ্য হলো প্রথমে মূল ওয়ার্কফ্লো সুরক্ষিত রাখা, তারপর দ্রুত পুনরুদ্ধার।

ফলব্যাক ও কিউ: অ্যাপ ব্যবহার যোগ্য রাখুন

যখন একটি বাহ্যিক 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) মৌলিক বিষয়গুলোর পর্যবেক্ষণ করুন

লেটেন্সি, এরর রেট, এবং ব্রেকার open/close ইভেন্টগুলো ট্র্যাক করুন। একক ব্লিপ নয়, sustained পরিবর্তনের উপর অ্যালার্ট।

সাধারণ ভুল যা ছোট ইস্যেকে ডাউনটাইমে পরিণত করে

অধিকাংশ API আউটেজ বড় করে আপনার অ্যাপ নিজেই। এটি সবচেয়ে খারাপভাবে প্রতিক্রিয়া করে: খুব দীর্ঘ সময় অপেক্ষা করা, অত্যধিকভাবে রিট্রাই করা, এবং একই ওয়ার্কারদের জড়িয়ে ফেলা যেগুলো সবকিছু চালায়।

এই প্যাটার্নগুলো কন্টেইনমেন্ট ঘটায়:

• প্রতিটি ত্রুটি রিট্রাই করা, এমনকি 4xx সমস্যা যেমন অবৈধ রিকোয়েস্ট, মেয়াদউত্তীর্ণ অথ, বা অনুপস্থিত পারমিশন।
• খুব দীর্ঘ টাইমআউট সেট করা "নিরাপদ হতে", যা থ্রেড, DB কানেকশন, বা জব রানার নিয়ে নীরবে ব্যবহার করে যতক্ষণ না আপনার ক্ষমতা শেষ হয়।
• আইডেমপটেন্সি ছাড়া create অপারেশন রিট্রাই করা, ফলে ডাবল চার্জ বা ডুপ্লিকেট শিপমেন্ট হতে পারে।
• ভুলভাবে কনফিগার করা সার্কিট ব্রেকার যা কখনই পুনরুদ্ধার করে না বা বারবার খোলে ও বন্ধ করে।
• আংশিক আউটেজকে মোট ব্যর্থতা হিসেবে আচরণ করা বদলে কেবল প্রভাবিত ফিচারটাই ডিগ্রেড করা উচিত।

ছোট ফিক্সগুলো বড় আউটেজ প্রতিরোধ করে: কেবল অস্থায়ী ত্রুটিগুলো রিট্রাই করুন (টাইমআউট, কিছু 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) ব্যবহারকারী দলের জন্য এটা মানে একবার টাইমআউট, রিট্রাই, আইডেমপটেন্সি, এবং ব্রেকার নিয়ম নির্ধারণ করে পরে নতুন সার্ভিসে সেই প্যাটার্ন প্রয়োগ করা।