简朴的系统。基于 .Net，只用了 9 个项目，其他系统大概需要 100 个。之所以利用这么少系统是为了追求极限的编译速度，这点需要从系统开始时就举办筹划，每台处事器的编译时间约莫是 10 秒。
11 万行代码，比拟流量来说很是少。
利用这种极简的方法主要基于几个原因。首先，不需要太多测试，因为 Meta.stackoverflow 原来就是一个问题和 bug 接头社区。其次，Meta.stackoverflow 照旧一个软件的测试网站，假如用户发明问题的话，往往会提出并给以办理方案。
纽约数据中心利用的是 Windows 2012，已经向 2012 R2 进级（Oregon 已经完成了进级），Linux 系统利用的是 Centos 6.4。
SSD
默认利用的是 Intel 330（Web 层等）
Intel 520 用于中间层写入，好比 Elastic Search
数据层利用 Intel 710 和 S3700
系统同时利用了 RAID 1 和 RAID 10（任何4+ 以上的磁盘都利用 RAID 10）。不害怕妨碍产生，纵然出产情况中利用了上千块 2.5 英寸 SSD，还没遇到过一块失败的情景。每个模子都利用了 1 个以上的备件，多个磁盘产生妨碍的情景不在思量之中。
ElasticSearch 在 SSD 上表示的异常精彩，因为 SO writes/re-indexes 的操纵很是频繁。
SSD 改变了搜索的利用方法。因为锁的问题，Luncene.net 并不能支撑 SO 的并发负载，因此他们转向了 ElasticSearch。在全 SSD 情况下，并不需要环绕 Binary Reader 成立锁。
高可用性
异地备份——主数据中心位于纽约，备份数据中心在 Oregon。
Redis 有两个从节点，SQL 有 2 个备份，Tag Engine 有 3 个节点，elastic 有 3 个节点，冗余一切，并在两个数据中心同时存在。
Nginx 是用于 SSL，终止 SSL 时转换利用 HAProxy。
并不是主从所有，一些姑且的数据只会放到缓存中
所有 HTTP 流量发送只占总流量的 77%，还存在 Oregon 数据中心的备份及一些其他的 VPN 流量。这些流量主要由 SQL 和 Redis 备份发生。
数据库
MS SQL Server
Stack Exchange 为每个网站都配置了数据库，因此 Stack Overflow 有一个、Server Fault 有一个，以此类推。
在纽约的主数据中心，每个集群凡是都利用 1 主和 1 只读备份的设置，同时还会在 Oregon 数据中心也配置一个备份。假如是运行的是 Oregon 集群，那么两个在纽约数据中心的备份城市是只读和同步的。
为其他内容筹备的数据库。这里还存在一个“网络范畴”的数据库，用于储存登岸凭证和聚合数据（大部门是 stackexchange.com 用户文件可能 API）。
Careers Stack Overflow、stackexchange.com 和 Area 51 等都拥有本身独立的数据库模式。
模式的变革需要同时提供应所有站点的数据库，它们需要向下兼容，举个例子，假如需要重定名一个列，那么将很是贫苦，这里需要举办多个操纵：增加一个新列，添加浸染在两个列上的代码，给新列写数据，改变代码让新列有效，移除旧列。
并不需要分片，所有工作通过索引来办理，并且数据体积也没那么大。假如有 filtered indexes 需求，那么为什么不更高效的举办？常见模式只在 DeletionDate = Null 上做索引，其他则通过为列举指定范例。每项 votes 都配置了 1 个表，好比一张表给 post votes，1 张表给 comment votes。大部门的页面都可以及时渲染，只为匿名用户缓存，因此，不存在缓存更新，只有重查询。
Scores 长短类型化的，因此需要常常查询。它只包括 IDs 和 dates，post votes 表格当下约莫有 56454478 行，利用索引，大部门的查询都可以在数毫秒内完成。
Tag Engine 是完全独立的，这就意味着焦点成果并不依赖任何外部应用措施。它是一个庞大的内存布局数组布局，专为 SO 用例优化，并为重负载组合举办估量算。Tag Engine 是个简朴的 windows 处事，冗余的运行在多个主机上。CPU 利用率根基上保持在2-5%，3 个主机专门用于冗余，不认真任何负载。假如所有主机同时产生妨碍，网络处事器将把 Tag Engine 加载到内存中一连运行。