Another technique to add to the mix if you can handle the additional complexity is to load or feature shed. If you can delay or just drop additional expensive application features during the exact time you need to scale or handle a burst, then your system has additional core app logic to handle requests. This can prevent the system getting wedged in a positive feedback loop.
See also the gamedev technique of having sacrificial assets or code, so when you need to free up space late in the schedule to ship, you have something you can actually shed.
Having something intentionally non-essential to cut is much better than discovering under pressure that everything is load-bearing
It’s also an old devops trick to put some GB files on the FS of critical systems (databases, ..) when there are no way to dynamically add more space/volumes and monitoring is not trusted.
Bit hard to explain though.
I think sacrificial ballast would be a good term, https://en.wikipedia.org/wiki/Ballast