Can't wait to end my next system design with "just buy more servers. scaling isn't really that hard."

I've done exactly this in many meetings. It's a balance between infra costs and dev time optimizing spend. Typically ping pongs back and forth.

There is a point where that becomes exponentially prohibitively expensive.

At a former startup where I worked as senior engineer, that was our original approach. Then one weekend we tripled our userbase and horizontally scaling required massive changes in database architecture, sharding solutions, etc.

"Just buy more servers and load balance" is the short painful route. Carefully planning out and taking advantage of scalable architecture that can be provided to you less expensively because it too, runs at scale is the hard method. The fact that its easy to shoot yourself in the foot with it doesn't make it the easy route.

>Then one weekend we tripled our userbase and horizontally scaling required massive changes in database architecture, sharding solutions, etc.

You took the short easy route out of the gate instead of building for what you were planning to handle. This is the opposite of what I espouse. If you were going about it my way, you build that in from the ground up. Harder and a bit bumpier to roll out from the get go, but has worked well for me in the past.

If you want to spend capital for an unpredictable eventuality that may never pass over taking advantage of another company's investment to scale cost... sure, that's definitely the hard route.

I wouldn't call it "good" or "intelligent", but it's definitely hard.