6 ms·

This reminds me of the multiple times VC's asked me "but will it scale to Facebook dimensions?"...Well - NO!. Pretty much nothing does. They had to write their

This reminds me of the multiple times VC's asked me "but will it scale to Facebook dimensions?"...Well - NO!. Pretty much nothing does. They had to write their own MySQL engine, for fucks sake. Because, apart from Facebook, no one has close to 40% of humankind as userbase. Conclusion: at a certain scale or level of execution, challenges change from a quantitative to a qualitative nature.

deleted 4y ago
[deleted]
davnicwil 4y ago
What I find interesting about this is that facebook themselves didn't, as far as it seems, ask that question early on. They built things just good enough, and just built out from there as they grew, fixing things as required for the usage they had. I think another example is writing their own PHP interpreter (or something like that) to speed up the backend when that became a legit concern at massive scale. I think this serves as an existence proof that 'will it scale' is often a meaningless question in the early days of a company. It doesn't matter. If it can't, deal with it then in an appropriate manner with all the specific context of how it's being used - regardless it's a good problem to have either way!
- ljf 4y ago
  This! I was helping a friend with a site he was building. He kept wanting to spend loads of money early on to make sure he could scale, but I advised him to stay cheap and lean - and worry about scale when he got there. He would have spent a lot of money on scale he ultimately would not need.
- amelius 4y ago
  I don't think this is entirely true, as a userbase may not grow gradually but with big jumps occasionally. For example, in moments right after the platform gets broad publicity. See also "the slashdot effect".
  - mschuster91 4y ago
    For sure, but a decent cloud setup will have no problems with load spikes or larger surges (unless they're so large you hit spending limits).
  - midoridensha 4y ago
    >See also "the slashdot effect". Yeah, I remember when that was a thing, so many years ago.... Does anyone still use that site now? I abandoned it at least a decade ago, because it had gotten so awful.
- ilyt 4y ago
  I go by "build for x2, plan for x10". Unless you're super-super-successful you won't see much more than that. And if you do, well you have a budget now.
- toast0 4y ago
  There's a few things going on. Part 1, don't do things that you should know won't survive a year of growth when you could do something that you think will at around the same cost. Sometimes people interpret "don't optimize prematurely" to somehow mean don't do things right the first time; if you can do it right the first time, you'll save some headache down the road. Part 2, if you build a complex product, it's hard to predict which parts of the product will see the most use, even if you can predict your overall growth rate (which is hard too). The longer you wait to make your product scale, the more information you have on what is actually used, and what you actually need to scale. Part 3, if you make some reasonable choices, with today's server hardware, you can do an awful lot of work on a single machine. Current generation Epyc is 96 cores per socket, and AMD says 6TB per socket as well, although 3TB per socket might be more realistically achievable. You can do an awful lot of computing with a two-socket, 192 core, 6TB machine, it will be expensive, but writing a check is a lot easier than sharding a relational database. Get a database server, maybe a big one, and horizontally scale the frontend is a sensible basic architecture that gets you pretty far these days.

deleted 4y ago

[deleted]

davnicwil 4y ago

What I find interesting about this is that facebook themselves didn't, as far as it seems, ask that question early on. They built things just good enough, and just built out from there as they grew, fixing things as required for the usage they had. I think another example is writing their own PHP interpreter (or something like that) to speed up the backend when that became a legit concern at massive scale. I think this serves as an existence proof that 'will it scale' is often a meaningless question in the early days of a company. It doesn't matter. If it can't, deal with it then in an appropriate manner with all the specific context of how it's being used - regardless it's a good problem to have either way!

ljf 4y ago
This! I was helping a friend with a site he was building. He kept wanting to spend loads of money early on to make sure he could scale, but I advised him to stay cheap and lean - and worry about scale when he got there. He would have spent a lot of money on scale he ultimately would not need.
amelius 4y ago
I don't think this is entirely true, as a userbase may not grow gradually but with big jumps occasionally. For example, in moments right after the platform gets broad publicity. See also "the slashdot effect".
- mschuster91 4y ago
  For sure, but a decent cloud setup will have no problems with load spikes or larger surges (unless they're so large you hit spending limits).
- midoridensha 4y ago
  >See also "the slashdot effect". Yeah, I remember when that was a thing, so many years ago.... Does anyone still use that site now? I abandoned it at least a decade ago, because it had gotten so awful.
ilyt 4y ago
I go by "build for x2, plan for x10". Unless you're super-super-successful you won't see much more than that. And if you do, well you have a budget now.
toast0 4y ago
There's a few things going on. Part 1, don't do things that you should know won't survive a year of growth when you could do something that you think will at around the same cost. Sometimes people interpret "don't optimize prematurely" to somehow mean don't do things right the first time; if you can do it right the first time, you'll save some headache down the road. Part 2, if you build a complex product, it's hard to predict which parts of the product will see the most use, even if you can predict your overall growth rate (which is hard too). The longer you wait to make your product scale, the more information you have on what is actually used, and what you actually need to scale. Part 3, if you make some reasonable choices, with today's server hardware, you can do an awful lot of work on a single machine. Current generation Epyc is 96 cores per socket, and AMD says 6TB per socket as well, although 3TB per socket might be more realistically achievable. You can do an awful lot of computing with a two-socket, 192 core, 6TB machine, it will be expensive, but writing a check is a lot easier than sharding a relational database. Get a database server, maybe a big one, and horizontally scale the frontend is a sensible basic architecture that gets you pretty far these days.