大型架构是一天生成的吗

今天，看到了这篇文章“Instagram Architecture: 14 Million users, Terabytes of Photos, 100s of Instances, Dozens of Technologies”http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html，回想起以前看的eBay的架构分析，豆瓣的架构分析等等很多的这种大型，超大型的架构分析，有一个问题一直困惑着我，这些架构是一天生成的吗？是天才程序员凭空设计出来的吗？还是跟我们平常做的一样，先从稍小的原型开始，逐步的扩展出来？后一种的问题在于发展到一定阶段很可能要推倒重来，然而前一种的问题在于复杂的不同的业务需求中，怎么就能一下子发现一种适合的设计方案，如果类似的业务，可能会有架构模板参考去设计，即便是类似，在没有上线压力的情况下你又怎么去判断架构真的是适合的？如果是新的业务呢？或者在设计之前要先有benchmark作为模拟去判断采用的架构方案是否合适？这种架构的设计是否完全依赖于一些天才程序员的能力或者还是有很多的准则可以去参考？
发在海版就是欢迎各位大大们随便侃，只言片语都好。

只有一种可能：“跟我们平常做的一样，先从稍小的原型开始，逐步的扩展出来？”

至于推倒重来什么的，有钱都不是问题。

没有小项目练手。。。。谁能一步登天啊。。。。。。只不过有些人从A能想到B，而有些人能从A一下想到D。。。。。

小项目练的再多也没用。原来我也这么想，但现在，越来越感觉到真的是靠天才程序员才能做的出来，或者至少有少数的程序员去引领方向。

在这个公司做一个小的, 积攒经验. 到另一个公司做个中等的, 再积一下. 这样一点一点做出来的.

小系统到大系统是业务规模驱动啊

螺旋式上升的过程，

开始时个小而全的麻雀，

撑不住了，重构：
上面按不同业务和特性垂直拆，
下面按技术需求，提取公用点，水平切，独立、合并。

系统分割成很多系统，力度更小，用途更简单直接，
某些子系统又慢慢膨胀了，再迭代上面的过程。

天下大事分久必合合久必分。
螺旋式发展。