सीधे सादे retries आउटेज को और बुरा क्यों बना देते हैं, और आप सुरक्षित retry पॉलिसी कैसे डिजाइन करेंगे?

सीधे सादे retries ठीक उसी वक्त लोड कई गुना कर देते हैं जब सर्विस पहले ही जूझ रही होती है, और एक साथ चलने वाले क्लाइंट कदम मिलाकर लहरों में retry करते हैं। full jitter के साथ exponential backoff इस्तेमाल करें, कुल कोशिशों की सीमा बांधें, और सिर्फ idempotent ऑपरेशन को उन्हीं एरर पर retry करें जिन पर retry जायज है। क्लाइंट साइड retry budget जोड़ें ताकि retries ट्रैफिक का छोटा हिस्सा ही रहें, साथ में circuit breaker ताकि फेल होने की दर उछलने पर कॉल पूरी तरह रुक जाएं। स्टैक की हर परत पर अलग अलग retry कभी न करें।

दिक्कत यह है कि retries सबसे बुरे पल में डाला गया अतिरिक्त लोड हैं। अगर कोई सर्विस 50% पर फेल हो रही है और हर क्लाइंट तीन बार retry करता है, तो आपने उस चीज पर आने वाला ट्रैफिक तिगुना कर दिया जो पहले ही क्षमता से ऊपर है, और उसे संभलने का मौका ही नहीं मिलता। सादा exponential backoff भी काफी नहीं है, क्योंकि आपके सारे क्लाइंट एक ही पल में फेल हुए थे, तो वे सब एक ही पल में जागते भी हैं। full jitter इसे ठीक कर देता है, यानी नींद शून्य और मौजूदा backoff सीमा के बीच कोई भी रैंडम वैल्यू होती है। इसके आगे मैं सिर्फ idempotent कॉल retry करूंगा, सिर्फ 503, 429 और कनेक्शन स्तर के एरर पर, 400 पर कभी नहीं, और मैं retry budget लागू करूंगा ताकि retries कुल रिक्वेस्ट के करीब 10% पर बंधे रहें। जिस चीज ने हमें काटा वह परतें थीं। SDK तीन बार retry करता था, mesh दो बार, और job runner फिर से, यानी एक तार्किक कॉल के लिए अठारह कोशिशें।