Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Scale a System from 0 to 10M+ Users

blog.algomaster.io

Post reply on HN
Print view View original

41–50 of 82 posts

Re: How to Scale a System from 0 to 10M+ Users

#41

Post by Nextgrid »

swiftcoder wrote: post #40
steveBK123 wrote: post #21

Earlier quoted context omitted.

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 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.

Re: How to Scale a System from 0 to 10M+ Users

#42

Post by steveBK123 »

Nextgrid wrote: post #41
swiftcoder wrote: post #40

Earlier quoted context omitted.

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 p…

> 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.

Re: How to Scale a System from 0 to 10M+ Users

#44

Post by sumitkumar »

mbb70 wrote: post #17
Nextgrid wrote: post #15

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 proprietar…

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.

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.

Re: How to Scale a System from 0 to 10M+ Users

#46

Post by tuetuopay »

efilife wrote: post #27
tallytarik wrote: post #22

Earlier quoted context omitted.

It’s entirely written by 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.

Re: How to Scale a System from 0 to 10M+ Users

#48

Post by techpression »

Nextgrid wrote: post #15

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 proprietar…

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.

Re: How to Scale a System from 0 to 10M+ Users

#49

Post by sofixa »

Nextgrid wrote: post #15

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 proprietar…

> 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.

Post reply on HN