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.
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.
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.
PEOPLE: can we not take everything so personally please? It's killing the country and some good HN threads.
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!
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
2. Write code that is maintainable. I don't advocate solving for problems that don't exist , but i cannot agree with building code specifically so that it is readily disposable.
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.
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.
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.
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.
Blindly repeating the erroneous meme that you don't need to scale for future users is doing an immense harm to these businesses.
2. Not going to help.