I really enjoyed reading this. Much like Instagram, which had thousands of users sign up on the first day, if you aren't able to scale because of your skill level, wouldn't that affect usage and lead to comments like: 'The app/site is so slow'?
Not criticizing the core idea, which is sound (don't waste ressource overengineering at the beginning, evolve your architecture to match your actual scale as you grow), but the “number of users” figures in this post are completely nonsensical. You ought to multiply them by 100 (if you're being conservative) or even 1000 (depending on the consumption pattern for the user).
Modern hardware is fast, if you cannot fit more than 100 users (not even 100 concurrent users) on a single $50/month server, you're doing something very very wrong.
Even repurposed 10 years old fairphone[1] can handle more than that.
> Modern hardware is fast, if you cannot fit more than 100 users (not even 100 concurrent users) on a single $50/month server, you're doing something very very wrong.
Depending on usage patterns you can go higher.
I put well over a few thousand users on a single $5/m DO droplet. The backend was a single Go binary updating a postgresql DB (on the same machine) as and when users finished their mandated training material, keeping track of which slide they were last on.
The actual training slides were served statically.
Python is slow; I mean, like really slow. Java and C# requires extra RAM, and not just a little - 1GB minimum for any webapp you intend to build.
Jenkins, written in Java IIRC, was not able to run on that $5/m droplet even serving just a couple of users. A Django app I built also had trouble with acceptable response times with just a a few users too.
My little Go binary, OTOH, peaked at 300MB RAM usage and had no problem even with 1000 users all logging in at 0800 and rapidly running through their training.
1) His user numbers are off by an order of magnitude at least, as other comments have mentioned. Even a VM/VPS should handle more, and a modern bare-metal server will do way more than the quoted numbers.
2) Autoscaling is a solution to the self-inflicted problem of insanely-high cloud prices, which cloud providers love because implementing it requires more reliance on proprietary vendor-specific APIs. The actual solution is a handful of modern bare-metal servers at strategic locations which allow you to cover your worst-case expected load while being cheaper than the lowest expected load on a cloud. Upside: lower prices & complexity. Downside: say goodbye to your AWS ReInvent invite.
3) Microservices. Apparently redeploying stateless appservers is a problem (despite the autoscaling part doing exactly this in response to load spikes which he's fine with), and his solution is to introduce 100x the management overhead and points of failure? The argument about scaling separate features differently doesn't make sense either - unless your code is literally so big it can't all fit in one server, there is no problem having every server be able to serve all types of requests, and as a bonus you no longer have to predict the expected load on a per-feature basis. A monolith's individual features can still talk to separate databases just fine.
I'm going to be charitable and assume he means "concurrent users" (i.e. something like 100 concurrent users would typically imply 2 orders of magnitude more total users...)
I believe less and less that scaling to hundreds of millions of user is not just a failure mode. There is a tipping point from which you only serve profits and shareholders/funders. Communities die by becoming too big.
I come to HN to read thoughtful posts written by humans. Why are we upvoting LLM slop to the front page?
It is frustrating that the awesome article about Nonograms currently has less than 70 upvotes. But this pure LLM slop has 100+ upvotes and counting! What would it take to stop this LLM slop infestation?
Can someone make a version of this that is not AI generated and ACTUALLY correct and pragmatic about the different stages with suggestions about the different scenarios that would lead to the different decisions?
20 comments
[ 3.6 ms ] story [ 30.5 ms ] threadModern hardware is fast, if you cannot fit more than 100 users (not even 100 concurrent users) on a single $50/month server, you're doing something very very wrong.
Even repurposed 10 years old fairphone[1] can handle more than that.
[1]: https://far.computer
Depending on usage patterns you can go higher.
I put well over a few thousand users on a single $5/m DO droplet. The backend was a single Go binary updating a postgresql DB (on the same machine) as and when users finished their mandated training material, keeping track of which slide they were last on.
The actual training slides were served statically.
Python is slow; I mean, like really slow. Java and C# requires extra RAM, and not just a little - 1GB minimum for any webapp you intend to build.
Jenkins, written in Java IIRC, was not able to run on that $5/m droplet even serving just a couple of users. A Django app I built also had trouble with acceptable response times with just a a few users too.
My little Go binary, OTOH, peaked at 300MB RAM usage and had no problem even with 1000 users all logging in at 0800 and rapidly running through their training.
1) His user numbers are off by an order of magnitude at least, as other comments have mentioned. Even a VM/VPS should handle more, and a modern bare-metal server will do way more than the quoted numbers.
2) Autoscaling is a solution to the self-inflicted problem of insanely-high cloud prices, which cloud providers love because implementing it requires more reliance on proprietary vendor-specific APIs. The actual solution is a handful of modern bare-metal servers at strategic locations which allow you to cover your worst-case expected load while being cheaper than the lowest expected load on a cloud. Upside: lower prices & complexity. Downside: say goodbye to your AWS ReInvent invite.
3) Microservices. Apparently redeploying stateless appservers is a problem (despite the autoscaling part doing exactly this in response to load spikes which he's fine with), and his solution is to introduce 100x the management overhead and points of failure? The argument about scaling separate features differently doesn't make sense either - unless your code is literally so big it can't all fit in one server, there is no problem having every server be able to serve all types of requests, and as a bonus you no longer have to predict the expected load on a per-feature basis. A monolith's individual features can still talk to separate databases just fine.
Author having this on his github makes me even more suspicious: https://github.com/ashishps1/learn-ai-engineering
I ran a 10k user classic ASP service on a VPS from Fasthosts, with MySQL 5.6 and Redis, and it was awesome.
It is frustrating that the awesome article about Nonograms currently has less than 70 upvotes. But this pure LLM slop has 100+ upvotes and counting! What would it take to stop this LLM slop infestation?
https://www.pangram.com/history/a4492704-2897-4cfb-b921-b281...