Traffic doubles and your service starts queuing requests until everything times out. What do you do about it?

Apply backpressure instead of buffering. Bound every queue, shed load early with a 429 or 503 when concurrency limits are hit, and reject requests whose deadline has already passed rather than working on them. Unbounded queues convert an overload into a latency collapse, because every request waits behind work nobody is waiting for any more. Prioritize by tier if some traffic matters more, and autoscale on a signal that leads, such as queue depth.

The instinct is to add a bigger queue, but that just converts an overload into slow failure, because every request sits behind a backlog and by the time it is served the client has already given up. So the first thing I do is bound the queue and add a concurrency limit, and when it is full I return 503 with a retry after immediately. Rejecting fast is kinder than timing out slowly, both for the user and for the system. Second, I check the deadline before doing the work: if the request has been waiting longer than its budget, I drop it, which frees capacity for requests that can still succeed. That single change is the one that visibly recovers throughput during an incident. Then prioritization, because not all traffic is equal; on one system we shed background sync traffic first and kept interactive requests flowing. And I scale on queue depth or concurrency rather than average CPU, since CPU flattens near saturation and reacts far too late to be useful.