How to Scale a System from 0 to 10M+ Users(blog.algomaster.io)
blog.algomaster.io
How to Scale a System from 0 to 10M+ Users
https://blog.algomaster.io/p/scaling-a-system-from-0-to-10-million-users
81 comments
Seems like LLM-written to me. Like, entirely.
Good post in general but some caveats:
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.
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.
As is often stated, microservices is a solution for scaling an engineering org to 100s of developers, not for scaling a product to millions of users.
You can get the separation benefits of microservices in a compiled language with modules that only communicate over well-defined interfaces, constraining each team within their own module without having to introduce a network call between each operation.
Python dev is cheaper and faster though. People arent gonna kill velocity by making their backend in c++ so the devs can have seperation of concerns, something that can, and should, be self enforced with discipline
Java or C# is a nice middle ground. But even in python you can enforce said separation - one module can only import from itself, libraries or any other module’s “services” object, and must export its functions in its own “services” object.
Microservices is bad for teams without discipline to implement "separation of concerns". They hope that physical network boundaries will force the discipline they couldn't maintain in a single codebase.
While microservices force physical separation, they don't stop "Spaghetti Architecture." Instead of messy code, you end up with "Distributed Spaghetti," where the dependencies are hidden in network calls and shared databases.
Microservices require more discipline in areas like:
Observability: Tracking a single request across 10 services. Consistency: Dealing with distributed transactions and eventual consistency. DevOps: Managing N deployment pipelines instead of one.
For most teams Modular monolith is often the better "first step." It enforces strict boundaries within a single deployment unit using language-level visibility (like private packages or modules). It gives you the "Separation of Concerns" without the "Distributed Spaghetti" network tax.
While microservices force physical separation, they don't stop "Spaghetti Architecture." Instead of messy code, you end up with "Distributed Spaghetti," where the dependencies are hidden in network calls and shared databases.
Microservices require more discipline in areas like:
Observability: Tracking a single request across 10 services. Consistency: Dealing with distributed transactions and eventual consistency. DevOps: Managing N deployment pipelines instead of one.
For most teams Modular monolith is often the better "first step." It enforces strict boundaries within a single deployment unit using language-level visibility (like private packages or modules). It gives you the "Separation of Concerns" without the "Distributed Spaghetti" network tax.
> Observability: Tracking a single request across 10 services
I'm not sure if this is a discipline issue in the way that domain driven design, say, is a discipline issue. If you instrument requests with a global ID and point at tool at it then you're basically done from the individual team perspective.
I'm not sure if this is a discipline issue in the way that domain driven design, say, is a discipline issue. If you instrument requests with a global ID and point at tool at it then you're basically done from the individual team perspective.
Uh, that's not my experience at all.
Sure you can say e.g "this property wasnt set in this request while being processed by this service managed by this team", but why it wasn't set will inevitably need multiple teams, each doing in-depth analysis how such as state could've been caused because they always inevitably become distributed monoliths - the former is being provided by the instrumentation, but the latter isn't (and even the former is not perfect, as not all frameworks/languages have equal support)
Sure you can say e.g "this property wasnt set in this request while being processed by this service managed by this team", but why it wasn't set will inevitably need multiple teams, each doing in-depth analysis how such as state could've been caused because they always inevitably become distributed monoliths - the former is being provided by the instrumentation, but the latter isn't (and even the former is not perfect, as not all frameworks/languages have equal support)
> and shared databases.
According to my understanding this is one of the reasons why microservices were invented, to prevent shared databases?
According to my understanding this is one of the reasons why microservices were invented, to prevent shared databases?
Unfortunately that message was way way behind the bombast of "microservices everywhere now" that preceded it for years, to the detriment of many small orgs.
I've seen engineering orgs of 10-50 launch headlong into microservices to poor results. No exaggeration to say many places ended up with more repos & services than developers to manage them.
I've seen engineering orgs of 10-50 launch headlong into microservices to poor results. No exaggeration to say many places ended up with more repos & services than developers to manage them.
The worst I ever saw was an engineer misunderstood microservices, and made a service per endpoint.
He started complaining to management that 50 CI/CD setups was his limit he could support.
He was absolutely amazed when I showed him he could combine endpoints into a larger logical service. 50 services became three, and it’s still three a few years later now.
He started complaining to management that 50 CI/CD setups was his limit he could support.
He was absolutely amazed when I showed him he could combine endpoints into a larger logical service. 50 services became three, and it’s still three a few years later now.
Nanoservices
I once worked with a startup that had 3 total engineers, and their architecture diagram called for 8 micro services. We tore that architecture diagram up pronto
Out of interest how do you get the authority to make those decisions and have the existing developers continue working productively after this?
To me it seems like microservices (or cloud, or whatever) is often overused for career/buzzword reasons. The engineers pushing for it aren't asking for your advice, they want to build an engineering playground - denying them the opportunity is unlikely to suddenly make them productive at driving the business forward with a simple stack when their original idea was to play with shiny tech instead.
The only way I see out of this is to have management buy-in to get the microservices and their developers out the door, replaced by more competent people.
To me it seems like microservices (or cloud, or whatever) is often overused for career/buzzword reasons. The engineers pushing for it aren't asking for your advice, they want to build an engineering playground - denying them the opportunity is unlikely to suddenly make them productive at driving the business forward with a simple stack when their original idea was to play with shiny tech instead.
The only way I see out of this is to have management buy-in to get the microservices and their developers out the door, replaced by more competent people.
> their original idea was to play with shiny tech instead
This is a behavior I would say is very hard to manage out of people and should be screened for aggressively in interviews.
This is a behavior I would say is very hard to manage out of people and should be screened for aggressively in interviews.
This behavior is self-inflicted by a decade of low pay and lack of significant raises to reward seniority.
The most effective way to increase income for a developer is to join a place, rack up as many buzzwords as possible and leave after 2-3 years, using those buzzwords to secure a higher-paying role somewhere else. Rinse and repeat until you get a management position where you can use politics to increase your income instead.
If you want guys that use boring tech to drive the business forward you have to pay them upfront the money they’d otherwise make playing the above game. It still makes sense (an engineering playground is anything but cheap) but good luck getting an employer to pay anything above “market rate”.
The most effective way to increase income for a developer is to join a place, rack up as many buzzwords as possible and leave after 2-3 years, using those buzzwords to secure a higher-paying role somewhere else. Rinse and repeat until you get a management position where you can use politics to increase your income instead.
If you want guys that use boring tech to drive the business forward you have to pay them upfront the money they’d otherwise make playing the above game. It still makes sense (an engineering playground is anything but cheap) but good luck getting an employer to pay anything above “market rate”.
The time up to and including Covid saw massive developer salary increases. They've dropped (and lots have been laid off) post-Covid, but the last ten years cannot be described as stagnation.
The salaries may be high in absolute terms, but they’re still low in relative terms - compared to what jumping ship would give you when you have a resume full of buzzwords.
> Out of interest how do you... have the existing developers continue working productively after this?
I don't know if you can in general - by happy coincidence the engineer who had made that plan found his way to the door shortly thereafter
I don't know if you can in general - by happy coincidence the engineer who had made that plan found his way to the door shortly thereafter
do they all manage to have 4 different ways to do something like "notify user about x", all In use because they could never be bothered to complete the "upgrade"?
That's often the case yes. In a monolith a developer disgruntled about the situation can clean up the mess in a weekend, test it and push it through. No chance of that happening in microservices - you'd run out of weekend just opening PRs in the dozens of repos and dealing with all the nitpicking and turf wars.
I've had the unfortunate experence to run into a situation where two dev's who hated eachother ended up building two systems with one passing the customer's API calls' http content directly to the front end... It was supposed to be back end and front end.
Exactly the problem yes.
Once you have more services than developers, you are probably running into infrequent releases and orphaned projects.
So whenever an inevitable common utility improvement is made, the effort of pushing out 100 repo releases for services no one has touch since Jim left 3 years ago is terrifying.
When there is a breaking change is going to be made and you HAVE to do the 100 releases, it's terrifying. Everyone says it never happens, but work on a project/team for 5 years and it does eventually, even once is enough to swear me off this "architecture".
So whenever an inevitable common utility improvement is made, the effort of pushing out 100 repo releases for services no one has touch since Jim left 3 years ago is terrifying.
When there is a breaking change is going to be made and you HAVE to do the 100 releases, it's terrifying. Everyone says it never happens, but work on a project/team for 5 years and it does eventually, even once is enough to swear me off this "architecture".
The best descripcion of microservices comes from "The Grug Brained Developer" (https://grugbrain.dev/):
"grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug"
"grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug"
Grug actually covers this in his essay:
> note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
Microservices definitely contribute to having a "large tribe of developer" to manage.
> note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
Microservices definitely contribute to having a "large tribe of developer" to manage.
Obligatory Krazam:
https://youtu.be/y8OnoxKotPQ
https://youtu.be/y8OnoxKotPQ
And to add to this: virtually every programming language allows you to define multiple entry points. So you can have your workers in the exact same codebase as your api and even multiple api services. They can share code and data structures or whatever you need. So, if you do need this kind of complexity with multiple services, you don’t need separate repos and elaborate build systems and dependency hell.
> 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
And how do you predict with certainty your "highest expected load"? And if you're in a space like ecommerce, where you have 1 week out of the year with x10 or x50 the load, I doubt it would actually be cheaper than using autoscaling. Especially today, with the costs of memory and storage. Not to mention that whenever you hit your load maximum, you have a few months of lead time to get extra capacity.
And FYI, "proprietary vendor-specific APIs" sounds very scary, but if you think about it for a few seconds, those APIs end at configuring an autoscaling group which is mostly about your min/max, and scaling rules. Yeah, it's proprietary, but it's 3-4 parameters to configure based on what you need, and from then little if any adjustment is needed. And you can take the same logic and port it to any other cloud provider within ~10 mins at most.
And how do you predict with certainty your "highest expected load"? And if you're in a space like ecommerce, where you have 1 week out of the year with x10 or x50 the load, I doubt it would actually be cheaper than using autoscaling. Especially today, with the costs of memory and storage. Not to mention that whenever you hit your load maximum, you have a few months of lead time to get extra capacity.
And FYI, "proprietary vendor-specific APIs" sounds very scary, but if you think about it for a few seconds, those APIs end at configuring an autoscaling group which is mostly about your min/max, and scaling rules. Yeah, it's proprietary, but it's 3-4 parameters to configure based on what you need, and from then little if any adjustment is needed. And you can take the same logic and port it to any other cloud provider within ~10 mins at most.
> And how do you predict with certainty your "highest expected load"? And if you're in a space like ecommerce, where you have 1 week out of the year with x10 or x50 the load, I doubt it would actually be cheaper than using autoscaling.
If you know when that week is, where's the problem in spinning up extra capacity just for that period, a week in advance?
Retailers, whether online or not, know with a very high confidence what their expected load is going to be a week from now.
If you know when that week is, where's the problem in spinning up extra capacity just for that period, a week in advance?
Retailers, whether online or not, know with a very high confidence what their expected load is going to be a week from now.
But you have to buy those servers, set them up, use them for that week, and then they're left idle for the whole of the year.
You don’t need to buy them, you can get them from AWS for that period only. Doesn’t mean your whole stack needs to be on AWS.
Doesn't mean, it significantly complicates state. Because the place that stores it (say, your bare metal machine with your database) is now the bottleneck.
None of the autoscaling solutions presented in the post address the database issue either.
I agree that in general the database is always going to be your bottleneck and autoscaling appservers is generally bullshit.
But let’s assume your DB is fine and you do actually need to scale appservers beyond what your provisioned capacity can allow, you can trivially spin up VMs at AWS or your provider of choice, Wireguard to your “VPC” at your bare-metal provider (or just SSH tunnel the ports) and run your appserver binary/container/etc on it.
Hell in a pinch you can do the above with your dev laptop and serve traffic from it. It will work and your customers won’t even be able to tell.
I agree that in general the database is always going to be your bottleneck and autoscaling appservers is generally bullshit.
But let’s assume your DB is fine and you do actually need to scale appservers beyond what your provisioned capacity can allow, you can trivially spin up VMs at AWS or your provider of choice, Wireguard to your “VPC” at your bare-metal provider (or just SSH tunnel the ports) and run your appserver binary/container/etc on it.
Hell in a pinch you can do the above with your dev laptop and serve traffic from it. It will work and your customers won’t even be able to tell.
> But you have to buy those servers, set them up, use them for that week, and then they're left idle for the whole of the year.
I didn't say you have to buy them. I said you can spin up extra capacity.
I didn't say you have to buy them. I said you can spin up extra capacity.
I was reading it and got seriously confused by separate database and server for a measly 1000 users. With the two separate you can scale vertically to handle a million users if all you’re doing is basic web/rest type stuff, probably more.
I feel a bit of sadness for people who had never used a bare metal server and seen how insanely capable hardware is today.
I feel a bit of sadness for people who had never used a bare metal server and seen how insanely capable hardware is today.
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.
[1]: https://far.computer
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.
[1]: https://far.computer
Counting in users is just nonsensical. Is it total registered users? Users per <time interval>? Sessions that need to go in the session store? Concurrent requests?
Then there's the implementation language category. interpreted, JITed vs. AOT.
And of course the workload matters a lot. Simple CRUD application vs. compute-heavy or serving lots of media, ...
Together those factors can make like 6+ OOMs difference.
Then there's the implementation language category. interpreted, JITed vs. AOT.
And of course the workload matters a lot. Simple CRUD application vs. compute-heavy or serving lots of media, ...
Together those factors can make like 6+ OOMs difference.
> 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.
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.
You and another person made this point _but_ I’d encourage you to look at what $50/mo gets you on AWS all in. In reality it will get you a t4g.small plus 200GB of (very slow) storage. Honestly they start to chug at 500 or so users in my experience.
For this you avoid AWS, Azure and GCP. Their pricing is simply not competitive. We operate root servers at Hetzner serving dynamic content to six-figure audiences.
PostgreSQL and Elasticsearch clusters can be operated at a fraction of the cost of comparable managed services offered by the major cloud providers.
The idea that this necessarily involves excessive maintenance effort is nonsense.
The skills needed to use hyperscalers properly are better invested in fundamental sysadmin know-how.
PostgreSQL and Elasticsearch clusters can be operated at a fraction of the cost of comparable managed services offered by the major cloud providers.
The idea that this necessarily involves excessive maintenance effort is nonsense.
The skills needed to use hyperscalers properly are better invested in fundamental sysadmin know-how.
Which is why you should not be going to AWS to begin with when there are plenty of providers who will give you orders of magnitude more performance for this price.
(of course, say goodbye to resume points and your cloud provider conference invite. Question is, what are you trying to do? Are you building a business, or a resume?)
(of course, say goodbye to resume points and your cloud provider conference invite. Question is, what are you trying to do? Are you building a business, or a resume?)
If you look at what $50 a month gets you at OVH or Hetzner then their post makes more sense.
It isn’t an apples to apples comparison. But, you trade some additional operational overhead for a whole lot more hardware.
It isn’t an apples to apples comparison. But, you trade some additional operational overhead for a whole lot more hardware.
Totally agree - I was just trying to give a perspective for the user scale figures
Agreed, the numbers were shockingly low.
Amazing to see my little phone pop up randomly on hacker news :D
Thank you stranger.
Thank you stranger.
This post shows some signs of having its parts written by a LLM in my opinion. Or am I crazy? Please tell me that I am.
Author having this on his github makes me even more suspicious: https://github.com/ashishps1/learn-ai-engineering
Author having this on his github makes me even more suspicious: https://github.com/ashishps1/learn-ai-engineering
It’s entirely written by an LLM.
LOL, I was having an online chat with a friend the other day and commented I sound like an LLM.
Are you sure?
Ask an LLM to write such an article and you'll have exactly this.
- random bold emphasis that would make disney and marvell comics blush
- overuse of "one paragraph then bullet points"
- a lot of the bullet lists has a small bold prefix then one line for no good reason
- every section has a "why it matters"
- and then each section with an useless comparison table that are direct screenshots of ChatGPT/Gemini
I would not mind if the author indeed used his alleged insights in the domain, but as other have noted, numbers are way off, and are what CSPs want you to believe to sell more instances in Kubernetes. This does not inspires "I proofread the LLM output".
It's a shame because the article has some good advices, but also a lot of misled ideas that would make Grug scratch their head. No, you don't need Redis to have stateless applications. Having a load-balancing tier is as useful for resiliency than it is for scaling. Autoscaling is a trap. If you can afford it, start with the app and DB separated. Let your application perform connection pooling itself from day one, your framework knows more than PgBouncer how connections can be safely reused.
Overall, at a high level, the article is good and is a good outline on the order in which to optimize (sharding is dead last), but the details don't meet expectations.
- random bold emphasis that would make disney and marvell comics blush
- overuse of "one paragraph then bullet points"
- a lot of the bullet lists has a small bold prefix then one line for no good reason
- every section has a "why it matters"
- and then each section with an useless comparison table that are direct screenshots of ChatGPT/Gemini
I would not mind if the author indeed used his alleged insights in the domain, but as other have noted, numbers are way off, and are what CSPs want you to believe to sell more instances in Kubernetes. This does not inspires "I proofread the LLM output".
It's a shame because the article has some good advices, but also a lot of misled ideas that would make Grug scratch their head. No, you don't need Redis to have stateless applications. Having a load-balancing tier is as useful for resiliency than it is for scaling. Autoscaling is a trap. If you can afford it, start with the app and DB separated. Let your application perform connection pooling itself from day one, your framework knows more than PgBouncer how connections can be safely reused.
Overall, at a high level, the article is good and is a good outline on the order in which to optimize (sharding is dead last), but the details don't meet expectations.
Yes. The over-use of bold in the intro (hell, in the first sentence) is a good hint.
All of it aligns with https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing
Maybe the images were made by hand.
All of it aligns with https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing
Maybe the images were made by hand.
[deleted]
> Or am I crazy?
You are not. The entire post is LLM slop. I am as baffled as you are how something like this could be on the front page of HN.
The senseless bolding of random words in the text, numbers that are way off and don't make any sense are the clues that the post is LLM generated and the blogger didn't even bother to proofread it.
You are not. The entire post is LLM slop. I am as baffled as you are how something like this could be on the front page of HN.
The senseless bolding of random words in the text, numbers that are way off and don't make any sense are the clues that the post is LLM generated and the blogger didn't even bother to proofread it.
Pangram reports the article is 100% AI generated
https://www.pangram.com/history/a4492704-2897-4cfb-b921-b281...
https://www.pangram.com/history/a4492704-2897-4cfb-b921-b281...
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?
This website itself is running on a single server and handles millions of requests per day. Raw number of users is simply not what decides the architecture, not even a little bit.
Echoing what others have said about the numbers being off.
I ran a 10k user classic ASP service on a VPS from Fasthosts, with MySQL 5.6 and Redis, and it was awesome.
I ran a 10k user classic ASP service on a VPS from Fasthosts, with MySQL 5.6 and Redis, and it was awesome.
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...)
[deleted]
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'?
Aren't comments like "the site is too slow" similar to "the city is too crowded"?
Twitter famously had a "fail whale" but it didn't stop the company from growing. If you have market demand (and I guess advertising) then you can get away with a sub-optimal product for a long time.
Twitter famously had a "fail whale" but it didn't stop the company from growing. If you have market demand (and I guess advertising) then you can get away with a sub-optimal product for a long time.
> Twitter famously had a "fail whale" but it didn't stop the company from growing. If you have market demand (and I guess advertising) then you can get away with a sub-optimal product for a long time.
Agreed, but there's still an element of survivorship bias there. Plenty of companies failed as they couldn't keep up with their scaling requirements and pushed the "getting away with a sub-optimal product" for too long a time.
Agreed, but there's still an element of survivorship bias there. Plenty of companies failed as they couldn't keep up with their scaling requirements and pushed the "getting away with a sub-optimal product" for too long a time.
Do you have some good examples?
This touches the toupet fallacy:
"I never saw a large company fail to grow large because of deferred scaling"
Friendster might fit though: https://highscalability.com/friendster-lost-lead-because-of-...
Friendster might fit though: https://highscalability.com/friendster-lost-lead-because-of-...
I agree. Go fast with a suboptimal architecture.
If success arise, throw away version 1 and rebuild from scratch. Often is more effettive.
Reddit is still around.
It depends on the adoption model.
If it’s just “sign up any time you want and go”, yes, it can go that way.
If it’s “join that waiting list” or “book a call” (for KYC purposes or whatever), you have a buffer.
If user count is more or less constant (most internal websites, for example), it’s probably not an issue.
And so on.
If it’s just “sign up any time you want and go”, yes, it can go that way.
If it’s “join that waiting list” or “book a call” (for KYC purposes or whatever), you have a buffer.
If user count is more or less constant (most internal websites, for example), it’s probably not an issue.
And so on.
[deleted]
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.
[deleted]
Does anyone have a similar guide for scaling AI systems? I am afraid this architecture cannot scale to 10M+ users serving LLMs for example.
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?
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?
someone please follow this LLM guide and let us know how miserably they failed
Just skimming the website, i call bs.
Nice read
srinath693(2)