学到的经验：
    不仅仅把你的应用程序看作一个web应用程序。你将会有使用到REST APIs,、SOAP APIs、 RSS feeds、 Atom feeds等；

   无界限化。无界限化能够让你的系统更加鲁棒，毫无顾虑的进行升级。

   高速缓存。尽量高速缓存和RAM来响应每个请求

    抽象化。在数据库，业务逻辑，页面逻辑，页面标签，和表现层之间创建很清晰的抽象层次。在迭代开发中将会很灵活好用。 
    分层。分层设计能够让开发者处理业务逻辑，而设计者能够进行用户体验页面设计。设计者还能在需要时请求页面逻辑。这两层之间有一个很好的协商。

    释放频率。每30分钟一次。

    忽略微小性能改善，不成熟的优化将灾难的根源。

    应用程序测试。要能轻松的在你的应用程序体系结构机制（如设置标签，负载均衡等）中插入或者移除新的硬件。

    忘记基准。对于获得容量的一般观念设置一个基准是很好的，但是，对于规划来说，设置基准并不好，人工测试会提供一个测试结果，对真实情况进行一个测试会是一个更好的方法。
确定最高限额

每个服务器能够达到的最大极限服务是多少？

每个服务器接近到最大极限有多近？这个趋势又是怎么样的？MySQL（disk IO）情况又是怎样的？SQUID (disk IO 或者 CPU )的情况又是怎样的呢？memcached(CPU 或者 network )情况又是如何的？

对用户的使用规律要敏感

    与上一年的第一个工作日相比，Flickr网站在今年的第一个工作日会增加20-40%的负载每周日平均要比这一周其它天增加40-50%负载 。对用户指数级的增张要求敏感。更多的用户意味着更多的内容，更多的内容意味着更多的连接，更多的连接意味着更多的请求。

负载高峰备用。要有能够处理高峰负载的计划

原文的url ： http://highscalability.com/flickr-architecture