একজন ডেভেলপার একটি ভয়েস-রাউটিং সিস্টেম পরীক্ষা করার সময় একটি সাময়িক কোয়ারেন্টাইন (quarantine) ব্যবস্থা যুক্ত করেছেন, যা কোনো ব্যর্থতার পর পরবর্তী কলটিকে ৩০০ সেকেন্ডের জন্য একটি ভিন্ন পথ ব্যবহার করতে বাধ্য করে। এই পরিবর্তনটি সফটওয়্যারটিকে বারবার একই ত্রুটিপূর্ণ পথ চেষ্টা করা থেকে বিরত রাখে, যা একটি ক্যাসকেড আউটজেজ (cascade outage) হওয়ার সম্ভাবনা কমিয়ে দেয়।

কেন পুরনো লজিকটি সমস্যা তৈরি করছিল

মূল রাউটারটি একটি কঠোর নিয়ম অনুসরণ করত: যখন একটি ওয়ার্কস্টেশন ব্যস্ত থাকত, তখন এটি কেবল একই পথ আবার চেষ্টা করত। যদি সেই পথটি বারবার ব্যর্থ হতো, তবে সিস্টেমটি ত্রুটিটি লগ করত কিন্তু তার আচরণ পরিবর্তন করত না। বাস্তবে, একটি সিঙ্গেল পয়েন্ট অফ ফেইলিওর (single point of failure) কলগুলোকে ব্লক করে রাখতে পারত কারণ সফটওয়্যারটি বারবার একই ডেড এন্ডে লুপ করছিল।

নতুন কোয়ারেন্টাইন মেকানিজম

এই আপডেটে তিনটি সীমাবদ্ধতা যুক্ত করা হয়েছে:

  • স্থায়ী নয় – একটি স্বল্প সময়ের পর কোয়ারেন্টাইন মার্কারটির মেয়াদ শেষ হয়ে যায়।
  • গ্লোবাল নয় – এটি কেবল ব্যর্থ হওয়া নির্দিষ্ট পথের ক্ষেত্রে প্রযোজ্য, প্রতিটি রুটের ক্ষেত্রে নয়।
  • সীমিত মেমরি – সিস্টেমটি একটি লোকাল ফাইলে ব্যর্থতা রেকর্ড করে এবং একটি নতুন পথ সফল হওয়ার সাথে সাথে এটি ভুলে যায়।

যখন কোনো স্পিচ অ্যাটেম্পট (speech attempt) ব্যর্থ হয়, রাউটারটি সেই পথের জন্য একটি “quarantined” ফ্ল্যাগ লিখে রাখে। পরবর্তী ৩০০ সেকেন্ডের জন্য, যেকোনো ইনকামিং রিকোয়েস্ট স্বয়ংক্রিয়ভাবে একটি বিকল্প পথে রি-রুট (reroute) হয়। একটি ভিন্ন রুটে রিকোয়েস্ট সফল হওয়ার সাথে সাথে ফ্ল্যাগটি মুছে যায়, যা নিশ্চিত করে যে এই সমাধানটি প্রয়োজনের চেয়ে বেশি সময় ধরে কার্যকর থাকে না।

সুবিধা এবং ঝুঁকি

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

এই পদ্ধতির কিছু ঝুঁকি রয়েছে। নেটওয়ার্কের সামান্য সমস্যা একটি কোয়ারেন্টাইন ট্রিগার করতে পারে যা কলগুলোকে কম কার্যকর রুটের দিকে ঠেলে দেয়, ফলে ল্যাটেন্সি (latency) বা খরচ বেড়ে যেতে পারে। যদি বিকল্প পথটিও খারাপ হয়ে যায়, তবে সিস্টেমটি বিভিন্ন রুটের মধ্যে বারবার পরিবর্তন হতে পারে, যা অস্থিরতা তৈরি করে। অপারেটরদের কোয়ারেন্টাইন মার্কারগুলোর ওপর নজর রাখা প্রয়োজন যাতে তারা বুঝতে পারেন যে রি-রুটটি ইচ্ছাকৃত নাকি কোনো গভীর সমস্যার লক্ষণ।

পরবর্তীতে যা খেয়াল রাখতে হবে

  • মেট্রিক্স (Metrics): ৩০০ সেকেন্ডের উইন্ডোটি উপযুক্ত কিনা তা দেখার জন্য কোয়ারেন্টাইনের ফ্রিকোয়েন্সি এবং সময়কাল পর্যবেক্ষণ করুন।
  • স্কোপ (Scope): টিমগুলো এই লজিকটি অন্যান্য সার্ভিসে প্রয়োগ করার চেষ্টা করতে পারে যা স্ট্যাটিক রিট্রাই প্যাটার্নের (static retry patterns) কারণে সমস্যার সম্মুখীন হয়।
  • অটোমেশন (Automation): ব্যবহারকারীরা সমস্যাটি বোঝার আগেই যাতে প্রোঅ্যাক্টিভ রক্ষণাবেক্ষণ করা যায়, সেজন্য কোনো পথ বারবার কোয়ারেন্টাইনে প্রবেশ করলে অ্যালার্ট যুক্ত করুন।

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

উৎস: dev.to-তে মূল ডেভেলপারের পোস্ট।

আলোচনায় যোগ দিন: https://t.me/GyaanSetuAi