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

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

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

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