Scaling to Millions of Users | Hacker News Reader

Scaling to Millions of Users

blog.benroux.me

84 pointsliquidise16 comments

I totally disagree. There's 2 secrets to scaling to millions of users:

1. You aren't going to have millions of users so any work you do to support it is stopping you from delivering features that will make your existing 10 clients happier.

2. Write code that can be replaced (i.e. design for change). When preparing a complex new system, discuss how it could be ripped out later, and what assumptions it has about other systems (which will restrict them when they want to change), and what assumptions the new system's users will have of it.

Be pragmatic: it's better to write something that's a bit of a hassle to replace later, rather than something with a perfect interface that can have drop-in replacements deployed effortlessly, if you can get the former out the door way faster.

Are you sure you totally disagree? The author seems to mostly agree with your first point -- don't spend too much effort or complexity on scalability until you actually need to scale:

If we focus on scale too early, we sacrifice a lot of the agility that we need early on. We need to think about our growth as getting more cargo on our journey. With each new customer we get a bit more valuable. We also get heavier and less agile. Our job as engineers is to patch the holes in the hull as we find them, and scale the size of the infrastructure at the right times.

> Are you sure you totally disagree?

An extremely bad-faith reply (calling my opinion and understanding wrong), but I will attempt to reply: His recommendation is to avoid complexity, because it will make it hard to scale later. I think complexity is fine, because 1. above + 2. if you're really worried about future scaling.

Flaming not necessary. You were not called "wrong." You were asked whether you considered the possibility that you and the OP could be in agreement at least partially.

PEOPLE: can we not take everything so personally please? It's killing the country and some good HN threads.

<EDIT> And even if you were called "wrong," who cares? it probably just means that your argument "could be wrong" so it's not you. And if it's you, then consider it a great anonymous tip for life improvement! And if you prove that someone else's argument is wrong, then guess what: you just helped a fellow human!

Did you read the article? You're agreeing with him completely.

I did, and I disagree with everything he said. Next time, try asking, when I read the article and he said X that sounds a lot like where you said Y; I see a lot of agreement so can you help me understand the difference?

Your second point is very important.

The architecture of a system depends on the load it's designed for. If you have (relatively) few users go for the easiest solution possible that work but make sure that all the components are decoupled enough that as soon as you grow and it cannot cope with the load you can throw it away and replace it with something that has adequate performance characteristics.

Greg Young did a great talk on this subject https://vimeo.com/108441214

1. Most companies will never have a million+ users. But what happens when yours does? This is the experience i have been living for the last year, and i am sharing the challenges that come with that growth.

2. Write code that is maintainable. I don't advocate solving for problems that don't exist [1], but i cannot agree with building code specifically so that it is readily disposable.

[1]: https://blog.benroux.me/good-problems-to-have/

Getting a million users is infinitely harder than scaling a system to handle a million users. Most systems could run comfortably on a Raspberry Pi.

I don't think the suggestion is to make sure your code is disposable. It's that you need to code for now and it's difficult to predict which code may become a candidate for disposal.

> Getting a million users is infinitely harder than scaling a system to handle a million users.

Depends on your context.

When you work at an established company, it may already have millions of users and any new project/change/feature may grab millions of them easily.

The audience here skews heavily to newer, smaller companies.

> i cannot agree with building code specifically so that it is readily disposable

This is the crux of our differing point of view. Mine is: all code is trash, and business requirements change.

I don't advocate for disposable code, but to at least spend a second thinking that it will eventually no longer provide a business value in line with its support burden, and to recognize that it may have some day reach the end of its lifetime of effectiveness. The code that strongly resists scaling is always the ones who baked in assumptions about the current situation (technical environment & business needs) that are extremely hard to unwind.

> Most companies will never have a million+ users. But what happens when yours does?

What a time wasting question! It's exactly the sort of premature overdesigning that you advocate against. The question is good for interviews to check for the scaling mindset but terrible in planning and design. The answer is: you use the same scaling techniques as published in numerous case studies/etc. and hire experienced engineers who've successfully scaled products before.

The real answer is: you re-evaluate your systems to see how they should change to adjust to the need to scale; and you design systems that avoid assumptions that stop them from scaling.

I totally agree with this however I actually found the original post to be quite reasonable. Unlike some, he was not advising that you build for scale from the beginning. Quite the opposite. For example, he makes sensible suggesting like optimizing queries & getting bigger servers instead of more servers.

1. There are plenty of projects that will get millions of users guaranteed soon after their launch. (None of which are HN startups)

Blindly repeating the erroneous meme that you don't need to scale for future users is doing an immense harm to these businesses.

1. So literally this doesn't apply to you.

2. Not going to help.

Reply on news.ycombinator.com