How much capacity does this workload actually need?

The model, so you can argue with it

Concurrency comes from Little’s Law:L = λ × W — requests in flight equals arrival rate times how long each one takes. 250 req/s at 120 ms means about 30 requests being handled at any instant, and that is what you must have capacity for, not the request rate itself.

Worker count divides that by per-worker concurrency, then divides again by target utilisation. Sizing to 100% is how you get an outage — queues grow without bound as utilisation approaches saturation, so latency degrades sharply well before you reach it. 70% is a reasonable default; go lower if traffic is spiky.

CPU is an input, not a guess. A worker's core appetite depends entirely on whether the work is CPU-bound (image processing, crypto) or I/O-bound (waiting on a database), so you state it and the tool multiplies. Memory carries 25% headroom per pod because memory is not compressible — an over-committed pod is OOM-killed rather than slowed down.

Treat the output as a starting point for a load test, not a final answer. It assumes requests are independent and evenly arriving, and it knows nothing about your GC behaviour, connection-pool ceilings, database contention, or the fact that real traffic arrives in bursts. Measure, then adjust.