Suppose there is a staging environment very strapped for resources as new development, data workloads and other applications grow. Ideally one would like to maintain production parity, even at the resource allocation level per each deployed item in the staging environment. For example, one of the 12 Factor App principles describes this, taking great pains to emphasize not just a shallow kind of parity with mocking or lightweight spoofed resources, but rather really maintaining parity by running the same resources in staging.
Obviously for projects that scale up a lot, you may be budget constrained and simply have no choice but to spoof some resources in staging, use "sample" data or microservice stubs with the same shape as what real dependencies will look like in production, and other sacrifices.
But one type of sacrifice that is difficult to approach is reducing the basic allocated resources, like CPU, RAM, disk access, networking resources, logging, etc., so that a deployment in the staging environment becomes quite a different entity if you are interested in testing behavior of the whole stack of components together.
There are various tools that can help you automatically reduce resource usage, such as auto-scaling in many cloud vendor environment and in kubernetes, which in effect can lead to "overcommitting" your staging environment if deployments are asking for the same kinds of resources as in production but being tuned to use less as a function of real load or other dynamic conditions.
My question is: what is the state of best practices or understanding about this practice of overcommitting resources in staging. How often does this type of requirement become a necessity from budget and what are the major principles to think about when designing a solution in that case? What about the flip side of the issue: that "the cost of doing business" for a particular deployed entity should have the cost of significant production parity in staging impounded in as a basic need?