जब कोई सर्विस ओवरलोड हो, तो लोड गिराने और स्केल आउट करने में से आप कैसे चुनते हैं?

autoscaling में मिनट लगते हैं, तो पहले लोड गिराएं और स्केल बाद में करें। लोड तब गिराएं जब अड़चन ऐसी चीज हो जिसमें आप जल्दी क्षमता नहीं जोड़ सकते, जैसे डेटाबेस, लाइसेंस वाली डिपेंडेंसी, या धीमी cold start वाली सर्विस, या जब कतारें उससे तेज बढ़ रही हों जितना आप कभी खाली कर पाते। सबसे सस्ता और सबसे कम जरूरी काम पहले गिराएं, Retry-After के साथ 429 लौटाएं, और उन रिक्वेस्ट को बचाएं जिनमें कमाई या सुरक्षा जुड़ी है।

लोड गिराना तुरंत होता है और स्केल करना नहीं, तो असली ओवरलोड में मैं पहले लोड गिराता हूं और क्षमता को बाद में पकड़ने देता हूं। बड़ा सवाल यह है कि अड़चन असल में है क्या। जब बंदिश डेटाबेस कनेक्शन की हो तब और stateless pod जोड़ना सच में नुकसानदेह है, क्योंकि हर नया pod अपना pool खोलता है और आप ढहने की रफ्तार बढ़ा देते हैं। एक flash sale के दौरान हमारे साथ ठीक यही हुआ, जब तक हमने आगे एक connection proxy नहीं लगाया और कुल कनेक्शन की सीमा नहीं बांधी। लोड गिराने के लिए मुझे साफ साफ ट्रैफिक श्रेणियां पसंद हैं। checkout और payment कॉल श्रेणी एक हैं और कभी नहीं गिराई जातीं, लॉग इन यूजर की ब्राउजिंग श्रेणी दो है, और anonymous crawling के साथ गैरजरूरी recommendation कॉल श्रेणी तीन हैं और सबसे पहले गिरती हैं। हम इसे edge पर एक concurrency limiter से लागू करते थे और Retry-After हेडर के साथ 429 लौटाते थे ताकि सलीके वाले क्लाइंट पीटने के बजाय पीछे हट जाएं। इसके साथ एक degraded मोड जोड़ दें जो कैश की गई लिस्टिंग दिखाए, तो जो ट्रैफिक मायने रखता है उसके लिए आप चालू रहते हैं।