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.
 

世事如棋

昨天和数字组的两个实权主管开会，因为前一次会议中，我和他们的VP有过一些言语交锋，这次我做好了打硬仗的准备。在准备过程中，我们最大的担心，就是不知道他们的底线。这时候，我想起了小时候学围棋，打谱的时候，无论是轮到谁走，总是先从黑方的观点看一遍局势，然后再从白方的观点看一遍局势。才能有客观的判断。于是我试着从他们的角度考虑了这个计划中他们的得失利弊，然后分析了他们可能让步的底线。

有了这种把握，我信心十足的开始会议，第一步就开门见山：“如果你们担心的是我们的样品难于产品化，我们可以在一周之内提供200个样品。让你做全面的质检。” 这一步完全出乎他们的意料， 他们的执行主管马上表示同意。并且保证他可以说服他们的VP.

这样会议进行了没有5分钟，他们就一反上次会议的态度，主动接受了我们的主要计划。

之后进行的更是如鱼得水，我们在技术细节上的把握，完全令他们折服了。最后他们说这个项目要和我们合作。我们当然顺水推舟，敲定了下一步的几个实施步骤。

另一个让我们担心的是他们的商业推广经理，正在另一面和我们竞争对手谈。可是今天的NYTimes说我们的竞争对手有法律上的麻烦，这使我的担心减轻了不少。数字组不太可能冒法律上的风险，去直接从竞争对手那里获得我们要给他们提供的产品了。