ट्रैफ़िक दोगुना हो जाता है और आपकी service requests कतार में लगाने लगती है, यहां तक कि सब कुछ timeout हो जाता है। आप क्या करेंगे?

buffering की जगह backpressure लगाएं। हर queue को सीमित रखें, concurrency की हद पार होते ही 429 या 503 के साथ जल्दी load shed करें, और जिन requests की deadline पहले ही निकल चुकी है उन पर काम करने की जगह उन्हें ठुकरा दें। बिना सीमा वाली queues overload को latency के ढहने में बदल देती हैं, क्योंकि हर request ऐसे काम के पीछे खड़ी रहती है जिसका अब कोई इंतज़ार नहीं कर रहा। अगर कुछ ट्रैफ़िक ज़्यादा अहम है तो tier के हिसाब से प्राथमिकता दें, और ऐसे संकेत पर autoscale करें जो आगे चलता हो, जैसे queue depth।

पहला मन तो बड़ा queue लगाने का करता है, लेकिन इससे overload बस धीमी नाकामी में बदल जाता है, क्योंकि हर request एक backlog के पीछे बैठ जाती है और जब तक उसका नंबर आता है क्लाइंट हार मान चुका होता है। इसलिए सबसे पहले मैं queue सीमित करता हूं और concurrency limit लगाता हूं, और भर जाने पर तुरंत retry after के साथ 503 लौटाता हूं। जल्दी मना कर देना धीरे धीरे timeout होने से बेहतर है, यूज़र के लिए भी और सिस्टम के लिए भी। दूसरा, काम शुरू करने से पहले मैं deadline जांचता हूं: अगर request अपने बजट से ज़्यादा इंतज़ार कर चुकी है तो मैं उसे गिरा देता हूं, जिससे उन requests के लिए क्षमता बचती है जो अब भी सफल हो सकती हैं। किसी घटना के दौरान throughput को दिखने लायक वापस लाने वाला यही एक बदलाव होता है। फिर प्राथमिकता, क्योंकि सारा ट्रैफ़िक बराबर नहीं होता; एक सिस्टम में हमने पहले background sync ट्रैफ़िक shed किया और interactive requests चलती रहने दीं। और मैं औसत CPU की जगह queue depth या concurrency पर scale करता हूं, क्योंकि saturation के पास CPU सपाट हो जाता है और इतनी देर से हरकत करता है कि किसी काम का नहीं रहता।