This is a delightful retelling; thanks for sharing.
> I know of absolutely no service which failed because it couldn't scale.
Genuine question: what about Friendster?
> I know of absolutely no service which failed because it couldn't scale.
Genuine question: what about Friendster?
I seem to recall that the Friendster team had more than one aborted rewrite before they got it right, and by then it was too late. Scaling social networks required a different bag of tricks than was popular at the time (e.g., database replication was well accepted as a best practice, but sharding worked much better). Talented people could still get it wrong.
Still, social networking illustrates how failing to scale is rare, and should practically never be the concern early on. Almost every social network that gained traction struggled to scale at times, but the vast majority of them overcame their challenges.
We poured sweat and tears and many sleepless nights into scaling the Tagged back-end from 10 machines to over 1,000, over time serving hundreds of millions of users. It was a tremendous amount of work, much more than building the initial product, and I don't think there's much we could have done early on to make later scaling easier.
More on the story: http://highscalability.com/blog/2011/8/8/tagged-architecture...
There is always scope for a botched execution or just pure bad luck. I wish someone shared more candid details of what happened at Friendster.
IMHO, if your investors need to be involved in seeking approval for handling scaling pains and on top of that if they reject it - there are deeper issues within the company (management issues, politics, technical incompetence, leadership issues).
So to clarify my point - any team could still screw up technical execution. However there is no reason that given a good team and support from within the company, a product can't be scaled.