[jcun4128]

> until you hit scaling wall

What kind of numbers am I looking for? Thousands of users? Ops/sec? I realize it is partly due to what your thing is doing eg. website vs. a complicated app.

Yeah it is a good problem to have assuming you have cash flow.

[GaelFG]

Of course it may vary a lot but i would say a hundred of thousands of users (100 000).

To explain the number, I assume a user will spend 1% of it's time on your app (that mean the average user spend around 15min per day (EVERY DAY) on your app, that may not sound impressive but it aldready is) and an nginx server on a powerfull machine could handle around 1k connection at the same time.

If you want to dig about an exemple of number far less abstract I remember stack overflow published their settings :

- https://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-...

- https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

The 2013 article state they could handle 148,084,883 page load per day with a single database server (but they did use two) for exemple.

[n0w]

When your service can no longer process requests as fast as they come in, you've hit a wall. Until then the simple solution is to allocate more resources to your service (i.e. scale vertically).

[maccard]

There's obviously a balance to be struck but the more often you do something the easier it is to do. If you have a simple app with a db, backend, frontend and proxy, vertically scaling every time you hit that wall is going to be very painful. A little complexity goes a long way - using a managed system adds a very small amount of complexity in exchange for some breathing room when you need it. The last thing you want when your service is in a death spiral is to start thinking about the practicality of migrating your db and taking the hours of downtime/working overnight/weekends to do it at a convenient time for your customers.