facebook architecture

I watched the talk on Facebook architecture here:

My notes are:
1) The trade-off between consistency and latency is the key that makes large scale website like Facebook possible.
They basically don't guarantee that each user will see consistent results in real-time. But those results will eventually be consistent.  This greatly reduce the latency for gathering the data.
I think the only use cases that actually require realtime distributed consistency is financial applications, anything that has to do with monetary transactions.

For example, Google search doesn't have to be consistent to two different users, located across the pacific ocean, searching the same term. So if one piece of search result is not available in US local server, they don't have to pull it from Asian local server before showing the search result.

2) Leverage open source movement.
They used LAMP, memcached, thrift and scribe really heavily. Having those robust tools as starting point saves a lot of in-house dev time for them.

3) It's OK to by-pass certain strict unit test and regression tests.
Again it's a trade-off between time-to-market with robustness. Facebook application is not mission-critical (yet), so they can allow to fail in production once-in-a-while. This gives them faster release cycles.