Marketing tells you a campaign will drive ten times normal traffic next Tuesday. What do you do?

Load test against the real bottleneck rather than the web tier. Derive per component capacity from current traffic and headroom, then examine what does not scale horizontally: database write throughput, connection limits, third party rate limits, and cloud quotas. Pre scale instead of trusting autoscaling to react in time, raise quotas in advance, prepare a shed and degrade plan, and staff on call for the window.

First I would pin down what ten times means, because ten times over a day is a different problem from ten times in the first four minutes of an email send, and campaigns are almost always the second one. Then I model each tier from current usage: if we run at 30% CPU at peak today, the stateless tier is easy, but the interesting parts are the ones that do not scale by adding pods. For us that was Postgres write throughput and a payment provider that had a rate limit we had never come close to, which needed a phone call and a week of lead time. I would run a load test that hits the real path, not a synthetic health check, and I would pre scale rather than relying on the autoscaler, because a cold start of ninety seconds is a lifetime in a spike. Finally, a written degrade plan: what we turn off first, who can flip it, and a shared channel with marketing so the send can be paused.