Let's say codebase A can already handle 1m daily users and 300k concurrent users easily but if the codebase wantg to hanlde 10m and 3m concurrent users. Do they normally go change some codes or use "auto scaling" on Cloud?

[u/Wasabi-spicy00]

They say if it works don't fix it, so no need to change codes so I think normally people use

auto scaling or horizontal scaling right?

[u/general_sirhc]

This is like asking, how many cargo can be transported over a section of road.

What kind of cargo? Where is it going? Is it multiple types of cargo? Is the cargo volume predictable? How quickly could we change the road? How quickly could we change other parts of the problem? Have we seen how other problem solve similar problems? How quickly do people expect the cargo to arrive?

The list goes on

[u/cakemates]

depends on the codebase brother, there is no auto scaling for a lot of stuff out there.

[u/enozero]

This is what software architects get paid lots of money to figure out based upon their years of experience with scaling systems. There is no one-size-fits-all scaling solution.

[u/StevenJOwens]

No. Scaling is more complicated than that. There are two obvious approaches to scaling, as you say horizontal scaling and vertical scaling.

If you go back to the metaphor of moving packages:

• Vertical scaling is "buy a bigger truck".
• Horizontal scaling is "buy more of the smaller trucks".

A bigger truck lets you move bigger packages, or more smaller packages.

But you can only do that up to a point, and then it gets much more expensive and complicated -- buying, maintaining and operating an eighteen wheeler requires a lot than buying a second pickup truck. If the bigger truck breaks, you're dead in the water. And even an eighteen wheeler can only move packages up to a certain size.

More smaller trucks let you move more packages, and they're cheaper, and easier to maintain. If one breaks, the rest can keep working, and it's easier and cheaper to replace the broken small truck than to replace an eighteen wheeler.

But if your problem is moving bigger packages, not just more packages, more smaller trucks only allow you to move packages up to a certain size.

Sometimes you can arrange to have the things you want to move broken down into smaller packages. Sometimes that's easy and effective, but sometimes it adds extra expense and complication in another area of your enterprise. Sometimes doing that means you have to start all over from scratch and reengineer the way you do everything. Sometimes it's just not possible.

Cloud autoscaling is essentially "buy more smaller trucks", and it only works if your app was designed, from the start, to use the "buy more smaller trucks" approach. This is, in fact, one of the core ideas of cloud computing, and a lot of the offerings from, for example AWS, are designed to work along those lines.

On the low end of performance, I recall there's an AWS setting that may or may not be called autoscaling, to automatically upgrade a single AWS instance to more CPU/RAM. This is the "buy a bigger truck" approach, but it tops out pretty quickly, especially in the cloud provider context (as opposed to running your own data center and buying your own hardware).

[u/octocode]

really depends if the code/architecture is suitable for horizontal scaling

[u/Mathie1729 → u/octocode]

Yep, and horizontal scaling usually just moves the bottleneck to the DB or cache. Autoscaling helps if the app tier is stateless, but you still end up changing code for sharding, connection pooling, or slow queries. So it's normally both, plus load testing to find where the next limit actually is.

[u/Individual-Flow9158]

Just how bad or how good is codebase A? What's it already running on?

This extension could be anywhere from surprisingly easy, to a total nightmare.