Fantastic to think 2 engineers can scale it so far. It is exciting to think that a small team from anywhere in the world can think up the next big thing and scale it easily from wherever.
I think the biggest takeaway here is "don't reinvent the wheel", which I think is also a big problem for every engineer/hacker. Because we tend to build our own solutions as soon as we don't like an element or how something is handled etc. But this also causes that you lose focus and forget the bigger picture ("our users don't care whether we wrote the db ourselves").
If my software engineering course left me with one thing, it was to remember the three rules of software, "reuse, reuse, reuse". I think it might have been quoted from Deitel & Deitel C++.
Even the 30+ million is not relevant, Facebook with already have all of those users. So they didn't buy any users, no revenue, no profit, just some technology which they much have been able to build themselves for a fraction of the price.
It is relevant since this was a technical talk. The speaker didn't even mention the Facebook acquisition; he just said that they've been in the news lately and can't talk about it.
30+ million users relevant to Facebook? Of course not.
30+ million users relevant to a talk about scaling? Absolutely. The title of the article is "How To Scale A $1 Billion Startup" - but it's a tech talk about how to scale to support their userbase, not a business talk about how to increase quarterly profits. Hence, the number of users is far more relevant to the discussion than how much they were bought out for.
I was at this talk, and I think that by far the most important point was that you should get great advisers and mentors. Instagram started with an okay stack and terrible configuration. They ended up doing great on both counts; now they have almost no downtime, they deploy several times an hour, and their comprehensive tests take only 5 minutes to run. Some of that came from skill and prior knowledge, but the majority from adaptability and the willingness to switch quickly when advisers (e.g. Adam d'Angelo) suggested better alternatives.
Really complicated? While I'm sure some of the deep details are messy, the overall architecture is textbook standard.
A search engine (SOLR), a load balancer (HAProxy), an app server (django), a replicated/sharded database (postgres) and a replicated k/v store (redis).
32 comments
[ 2.9 ms ] story [ 83.6 ms ] thread“surely we’ll have hired someone experienced before we actually need to shard”
one
screen
at
a
time?
Hammer down and there are some good quotes/ideas in there.
For most of us on HN, though, I think only these slides are needed:
180 don't over-optimize or expect to know ahead of time how site will scale
184 few, if any, unsolvable scaling challenges for a social startup
185 have fun
30+ million users relevant to a talk about scaling? Absolutely. The title of the article is "How To Scale A $1 Billion Startup" - but it's a tech talk about how to scale to support their userbase, not a business talk about how to increase quarterly profits. Hence, the number of users is far more relevant to the discussion than how much they were bought out for.
I'm surprised that the number of engineers is so low, considering that they had 15 employees.
Maybe the figures above don't include mobile engineers? But then what would the other 2.5 be doing?
Thanks to Instagram and AirBnb for putting this on. It was an amazing event.
(Amazon and cloud are the unsung heroes.)
A search engine (SOLR), a load balancer (HAProxy), an app server (django), a replicated/sharded database (postgres) and a replicated k/v store (redis).