Wave是一家拥有70名工程师的17亿美元的公司，其产品是一个加减数字的CRUD应用程序。为了与此保持一致，我们的架构是一个标准的CRUD应用架构，一个Python单体在Postgres之上。从一个简单的架构开始，并尽可能用简单的方法解决问题，使我们能够扩展到这样的规模，而工程师们大多专注于为用户提供价值的工作。
Stackoverflow扩大了单体架构的规模，取得了良好的效果（2013年架构/2016年架构），最终以18亿美元的价格被收购。
如果我们看的是流量而不是市值，Stackoverflow是互联网上流量最高的前100个网站之一
我们没有大量的网络流量，因为我们是一个移动应用程序，但Alexa仍然把我们的网站放在前75000名。
将一个简单的单体架设在枯燥的数据库之上，可能不适合一些应用类型的需求，但是，对于大多数应用类型来说，即使是在前100个网站的流量水平上，计算机的速度也足够快，它们可以用简单的架构来提供服务，这通常可以比复杂的架构更便宜，更容易创建。
尽管简单架构的效果不合理，但大多数媒体都关注复杂架构。
例如，在最近的一次通才技术会议上，有六场关于如何构建或处理复杂的、基于微服务的架构的副作用以及如何构建一个简单的单体应用的零讨论。最近在 SF 举行的面向企业的会议就处理复杂架构的复杂性进行了两位数的讨论，而关于如何构建简单的单体应用则为零。
我们的架构非常简单，我甚至不会为架构图而烦恼。相反，我将讨论我们所做的一些无聊的事情，以帮助我们保持无聊。
我们目前正在使用无聊的Python同步锁，这意味着我们的服务器进程在等待 I/O 时会阻塞，例如网络请求。
我们之前尝试过 Eventlet，这是一个异步框架，理论上它可以让我们从 Python 中获得更高的效率，但是遇到了很多错误，以至于我们认为等待事件的 CPU 和延迟成本与痛苦处理 Eventlet 不成比例。从某种意义上说，我们为在网络请求期间只做等待的 CPU 付费，但由于我们每月只处理数十亿个请求（目前），即使使用慢速语言，如 Python，并支付零售公共云价格。我们工程团队的成本完全支配了我们运营的系统的成本。
与其承担使我们的单体架构变成复杂的异步性，不如把长期运行的任务（我们不希望响应阻塞）交给一个队列。
。。。点击标题更多
通过使我们的应用程序架构尽可能简单，我们可以将复杂性（和人数）预算用于有利于我们业务的复杂性的地方。
除非有充分的理由增加复杂性，否则尽可能简单地做事的想法使我们能够建立一个相当大的业务，尽管经营着非洲金融业务，但工程师人数并不多，这通常被认为是一项艰难的业务进入。
Reddit网友讨论
在许多情况下，单体架构可能是最佳的。Crud 应用程序似乎是最好的用例。借助负载均衡器、简单的 api 层、可分片的底层数据库，也许还有内存缓存层，一个 crud 应用程序可以支持数百万用户。
但是，并非所有应用程序都是杂乱无章的应用程序。许多应用程序都有搜索和聚合等要求。许多应用程序的读写比率差异很大，这使得缓存更容易或更难。还有数据一致性要求和分析。
甚至随着时间的推移，一个简单的 crud 应用程序也可以长出许多附属物。
在这些情况下，一个简单的单体可能是一个糟糕的决定。
当 CI 构建时间变得非常长时，通常会变得非常明显，并且发布过程变得越来越复杂以适应 crud 应用程序的相对复杂性。
微服务目的并非为了解决技术问题，它是为了解决组织问题。
单体非常适合一个小型的专门团队。就像在初创公司中看到的那样。
当肉汤变得足够大以至于你需要很多厨师来搅拌它时，问题就开始了。
当团队变大时，它就会失去凝聚力，代码库也是如此。
在大型单体应用中执行标准非常困难：有足够多的功能时，就很难区分什么功能是什么，这就可能开始影响稳定性。做出改变变得越来越难。我已经看到它发生在多个公司。这总是同样的故事。
微服务（或仅仅是领域服务）不会神奇地使一切变得更好。
但如果做得好的话，它们至少可以让我们更容易适应变化。