Hacker News new | ask | show | jobs
by GaelFG 1666 days ago
my two cents : until you hit scaling wall (and when you will congratulations, you are either successfull or a video streaming platform), a big server to upgrade is the best way to go and focus on building product.

Then you hit performance problems, any sysadmin could help you handle 2x/4x/10x scaling with simple separations of service and maybe some hours of downtime. In the meantime you probably have weeks/months to think about going really crazy with your infrastructure.
1 comments
jcun4128 1666 days ago
> 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.

link
GaelFG 1666 days ago
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.

link
n0w 1666 days ago
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).
link
maccard 1666 days ago
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.
link