मार्केटिंग आपको बताती है कि अगले मंगलवार एक कैंपेन से सामान्य से दस गुना ट्रैफिक आएगा। आप क्या करेंगे?

web tier की जगह असली अड़चन पर लोड टेस्ट करें। मौजूदा ट्रैफिक और बची गुंजाइश से हर हिस्से की क्षमता निकालें, फिर देखें कि क्या क्या horizontally स्केल नहीं होता: डेटाबेस का write throughput, कनेक्शन की सीमाएं, third party rate limit, और क्लाउड quota। autoscaling के समय पर संभल जाने के भरोसे रहने के बजाय पहले से स्केल करें, quota पहले ही बढ़वाएं, लोड गिराने और degrade करने का प्लान तैयार रखें, और उस विंडो के लिए on call स्टाफ लगाएं।

पहले मैं यह पक्का करूंगा कि दस गुना का मतलब क्या है, क्योंकि पूरे दिन में दस गुना और ईमेल भेजे जाने के पहले चार मिनट में दस गुना अलग अलग समस्याएं हैं, और कैंपेन लगभग हमेशा दूसरी वाली होती है। फिर मैं मौजूदा इस्तेमाल से हर परत का मॉडल बनाता हूं: अगर आज चरम पर हम 30% CPU पर चलते हैं, तो stateless परत आसान है, पर दिलचस्प हिस्से वे हैं जो pod जोड़ने से स्केल नहीं होते। हमारे लिए वह Postgres का write throughput था और एक payment provider जिसकी rate limit के पास हम कभी पहुंचे ही नहीं थे, जिसके लिए एक फोन कॉल और एक हफ्ते की मोहलत चाहिए थी। मैं ऐसा लोड टेस्ट चलाऊंगा जो असली रास्ते पर पड़े, किसी बनावटी health check पर नहीं, और मैं autoscaler के भरोसे रहने के बजाय पहले से स्केल करूंगा, क्योंकि नब्बे सेकंड की cold start उछाल के दौरान एक युग होती है। आखिर में, एक लिखा हुआ degrade प्लान: हम सबसे पहले क्या बंद करते हैं, उसे कौन पलट सकता है, और मार्केटिंग के साथ एक साझा चैनल ताकि भेजना रोका जा सके।