Why pod counts stay a directional guess until real load tests run

Start with the state that sets the ceiling. The four states are not four numbers of equal weight. Idle is the floor, what you pay for whenever the pod is up and doing nothing ^[5]. Normal load, the band the system occupies 90-95% of the time, is what most of the infrastructure bill is made of ^[6]. Peak is less a capacity figure than a commitment: the article's framing is that you have tested up to that number and you own it ^[7]. Startup is the odd one, because heavy initialization, cache pre-loads and migrations can push consumption well above idle ^[4], which makes it the state that decides how tight a pod's upper bound can be set without the process dying on the way up.

The placeholder in the CTO section is where the arithmetic gets interesting. Multiply it out and you get 1,536MB of memory with 6 cores at the floor, 12,800MB with 50 cores at the top, an 8.3x spread ^[17]. That range is honest about being a range. It is also useless for capacity planning, and the distance between its ends is roughly the size of the argument a sizing meeting is trying to have without data.

On bigger pods versus more pods, the outline poses the question as a section heading ^[14] and the supplied text never reaches an answer, so here is mine with the context attached. Once a load generator can hold a fixed request rate, this is measurable in an afternoon:

1. Run a single instance at the resources you think it needs. 2. Raise concurrency until latency crosses your budget, and record requests per second per core at that point. 3. Double the pod's CPU and memory and repeat step 2. 4. Compare throughput per core across the two runs.

If throughput per core holds, the workload scales inside the pod and fewer, larger pods buy you less orchestration overhead per unit of work. If it flattens, something in the process is serialised, the extra cores will sit idle, and you spend the same money on more replicas instead. My context is JVM services with generous heaps, where doubling usually does hold; I would not carry that result to a single-threaded worker without rerunning the same four steps.

One crack worth pinning down before you copy the method. Normal load appears twice with different definitions: 90-95% of the time in the state list, a flat 95% average in the four-question checklist ^[19]. Five points of tail is exactly where the peak run gets its inputs, so it matters which one your measurement actually covered.