So round it, this is engineering, not math. The safety buffer factor accounts for any rounding errors anyways.

The formula for number of needed servers seems like a fine approximation; I'm very confused how you could use the pigeonhole principle. Perhaps to say that if you have N servers, one of them has at least total_users/N users? But assuming you have a decent methodology for balancing users across servers, and can rebalance to use a new server when added, this has basically the same effects as the formula given so I'm clearly missing why you pointed this out.

The only difference in this case is to take the ceiling. The formula seems fine as an approximation.

The formula/metric is clearly an approximation?

Use it how? The actual pigeonhole principle would conclude that you have multiple users on at least one server, and nothing else.

And anything that calculates individual users is the wrong way to do this math.

As others have pointed out for the authors discussion this fact doesn’t really matter.

However what does matter is that the authors probably is not estimating the average correctly partially due to this bug. If they scaled without fixing their excessive string storage, they would probably find their estimate to be off.

Even with the fix I’d be surprised if the underlying distribution of data per user is normally distributed.

That can obviously be rounded. Nobody will really try to purchase 27% of a server. A different issue is that the formula should include "1+Safety Buffer". Otherwise it needs to be run twice, once with the safety buffer and once without. Even so, I didn't take the formulae on this page to be accurate so much as representational.

I assumed the "Safety Buffer" is really more of a "Safety Factor", and is equivalent to 1 + what you or I would call a Safety Buffer.

Yep. It's really a non-issue. It's was pretty clear to me that the author knows how to use the formula.

It relies on common sense, thing that you lack.

The real formula we used to order servers was more complex than this, and included regional distribution, requirement peaks etc. I can expand more on that process if this is interesting. However, for the context of this post, this crude approximation suffices IMO