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

एक प्रमुख कारण यह है कि आज का रीट्राई व्यवहार संदर्भ-जागरूक नहीं है। जबकि हम नियंत्रित कर सकते हैं कि कितने रीट्राई होते हैं, हम ठीक से नियंत्रित नहीं कर सकते कि वे कब होते हैं। यह एक सेवा द्वारा उत्पन्न त्रुटियों और केवल उसके माध्यम से प्रसारित त्रुटियों के बीच विश्वसनीय रूप से अंतर करने की चुनौती से उत्पन्न होता है। परिणामस्वरूप, रीट्राई सशर्त के बजाय समान रूप से लागू होते हैं। यह दृष्टिकोण क्षणिक या कम-दर विफलताओं के लिए काम करता है। हालांकि, मध्यम या गंभीर गिरावट के दौरान, यह प्रतिकूल हो जाता है।

पहले से ही संघर्ष कर रही सेवा के खिलाफ आक्रामक रूप से रीट्राई करना लोड बढ़ाता है, विफलता को तेज करता है, और अपस्ट्रीम निर्भरताओं में रीट्राई ट्रैफ़िक को बढ़ाता है। जो स्थानीयकृत आउटेज के रूप में शुरू होता है, वह जल्दी से स्टैक-व्यापी घटना में बदल सकता है—अंततः अंतिम उपयोगकर्ता अनुभव को ख़राब करता है, या सबसे खराब स्थिति में, पूरी तरह से तोड़ देता है।

कोई तर्क दे सकता है कि डाउनस्ट्रीम सेवाओं से त्रुटि कोड को रीट्राई के लिए संदर्भ प्रदान करने के लिए अपस्ट्रीम में अनुवादित किया जा सकता है। जबकि सैद्धांतिक रूप से संभव है, यह दृष्टिकोण Uber में बड़े फैन-इन और फैन-आउट, विकसित हो रहे कॉल प्रवाह, और लगातार अनुकूली परिवर्तनों की आवश्यकता के कारण स्केल नहीं करता है। इसलिए, हमने त्रुटियों को अधिक कुशलता से संभालने के लिए साझा अवसंरचना में एक संदर्भ-जागरूक तंत्र विकसित किया। यह ब्लॉग तंत्र की व्याख्या करता है।