网站现在运行地很稳定，响应也很快，不再需要依赖每隔几小时的服务器重启就能搞定当前常规的新用户请求。我们经历并成功挺过了第一次架构拓展升级的危机，得以让我们的网站变得更强大。这为我们的发展赢得了宝贵的时间。我们的厨房（应用服务器）和我们的储藏室/图书馆（数据库服务器）处于两栋不同的建筑中。就像相邻的两栋房子，我们的两台服务器同属班加罗尔的某个数据中心，它们之间通过极速的光纤相连。当我们的Django

对于我们要完成的MVP，这个特性还用不上，但即使暂时用不到全部功能，从一开始就选择一个功能强大的地基，在将来无疑也是会受益颇多。在众多的关系型数据库中（比如MySQL，微软的SQL Server等等），我们最终选择了PostgreSQL（常被简称为Postgres）。有了合适的编程框架，我们需要决定在哪持久化保存我们的业务数据，比如店铺名称，商品明细，价格等等。对于一个周末的黑客松项目来说，只有一

我们面对的是电商领域经典的业务难题。如果我们选用一个流行的NoSQL数据库，倒像是不合时宜地杀鸡用牛刀。PostgreSQL就是那个精准契合我们业务场景的可靠且强大的工具。我们相信采用PostgreSQL作为基础数据库足以满足业务增长的需求，甚至应对独角兽级别（10亿美金）的业务量也没问题。但在现代技术环境中，一个因此自然而生的问题是：为什么一定要用传统的关系型SQL数据库呢？如前所述，我们成功实

比如我们的用户注册，商品名录，订单管理，商户仪表盘，支付，所有功能都同处在一个Django（Python流行的web框架）项目里面。我们那运行在小得可怜的服务器上的大单体应用成了一个潜在的完美毁灭风暴：一个软件层面的单点（Single Point of failure）运行在一个硬件层面的单点。最重要的是（也是那天晚上导致我们网站崩溃的原因）, 大单体应用让你别无选择：如果你仅仅想为食谱书中某一部