# Stack Overflow: The Hardware - 2016 Edition

DevFeed: [Stack Overflow: The Hardware - 2016 Edition](<https://devfeed.tech/articles/stack-overflow-the-hardware-2016-edition-21591.md>)

Original publisher: [Read original article](<https://nickcraver.com/blog/2016/03/29/stack-overflow-the-hardware-2016-edition/>)

Published: 2016-03-29T00:00:00Z

Content type: article

Language: en

Sources: [Nick Craver](<https://devfeed.tech/sources/nick-craver.md>)

Topics: [Hardware](<https://devfeed.tech/topics/hardware.md>), [Stack Overflow](<https://devfeed.tech/topics/stackoverflow.md>), [Server](<https://devfeed.tech/topics/server.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [blog](<https://devfeed.tech/tags/blog.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [performance](<https://devfeed.tech/tags/performance.md>), [server](<https://devfeed.tech/tags/server.md>)

## AI overview

This article describes the hardware foundation of Stack Overflow's 2016 architecture. It presents an inventory of the site's infrastructure for reference and comparison, and explains how servers are specified according to their intended workloads and their role in the broader architecture.

## Source excerpt

This is #2 in a very long series of posts on Stack Overflow's architecture. Previous post (#1): Stack Overflow: The Architecture - 2016 Edition Next post (#3): Stack Overflow: How We Do Deployment - 2016 Edition Who loves hardware? Well, I do and this is my blog so I win. If you don't love hardware then I'd go ahead and close the browser. Still here? Awesome. Or your browser is crazy slow, in which case you should think about some new hardware. I've repeated many, many times: performance is a feature. Since your code is only as fast as the hardware it runs on, the hardware definitely matters. Just like any other platform, Stack Overflow's architecture comes in layers. Hardware is the foundation layer for us, and having it in-house affords us many luxuries not available in other scenarios...like running on someone else's servers. It also comes with direct and indirect costs. But that's not the point of this post, that comparison will come later. For now, I want to provide a detailed inventory of our infrastructure for reference and comparison purposes. And pictures of servers. Sometimes naked servers. This web page could have loaded much faster, but I couldn't help myself. In many posts through this series I will give a lot of numbers and specs. When I say "our SQL server utilization is almost always at 5-10% CPU," well, that's great. But, 5-10% of what? That's when we need a point of reference. This hardware list is meant to both answer those questions and serve as a source for comparison when looking at other platforms and what utilization may look like there, how much capacity to compare to, etc. How We Do Hardware Disclaimer: I don't do this alone. George Beech (@GABeech) is my main partner in crime when speccing hardware here at Stack. We carefully spec out each server for its intended purpose. What we don't do is order in bulk and assign tasks later. We're not alone in this process though; you have to know what's going to run on the hardware to spec it optimally.