How Stack Overflow Handles 5.6 B Monthly Visits with Only 25 Servers

Abstract: Stack Overflow runs on a modest 25‑server fleet, leveraging both Linux and Windows, heavy use of static methods and classes, and a philosophy that hardware is cheaper than developer time, resulting in extremely low resource utilization.

Scale and Traffic

With 4 million users, 8 million questions, 40 million answers, and 5.6 billion monthly page views, the site ranks 54th globally. Peak load reaches 2 600–3 000 requests per second on weekdays.

Infrastructure Overview

25 servers total (11 web, 4 DB, 3 tag engine, 3 search, 2 Redis, plus network gear)

384 GB RAM and 2 TB SSD for SQL Server storage

Web servers run IIS on Windows 2012 (upgraded to R2); Linux servers run CentOS 6.4

Load balancing via HAProxy (active) and Nginx for SSL termination

Platform Components

ElasticSearch for search

Redis for distributed caching and messaging

HAProxy for load balancing

MS SQL Server as the primary database

Opserver and TeamCity for monitoring and CI

Jil (fast .NET JSON serializer) and Dapper (micro‑ORM)

User Interface

The UI uses a WebSocket‑driven inbox, ElasticSearch‑backed search, and a tag‑engine that serves personalized question feeds based on user behavior.

Storage and SSD Strategy

Intel 330 SSDs for web tier

Intel 520 SSDs for middle‑tier writes (e.g., ElasticSearch)

Intel 710 and S3700 SSDs for data tier

RAID 1 and RAID 10 configurations across all disks

High Availability

Geographically separated primary (New York) and backup (Oregon) data centers

Redundant Redis, SQL, tag engine, and ElasticSearch nodes

77% of HTTP traffic handled directly, with additional backup traffic from replication

Database Design

Each Stack Exchange site has its own SQL Server instance with a primary‑read‑only replica in New York and a backup replica in Oregon. Schemas are shared across sites and evolve with backward‑compatible migrations.

Caching Layers

Level 1: Browser, CDN, and proxy caches

Level 2: .NET HttpRuntime.Cache (in‑memory per server)

Level 3: Redis distributed cache

Level 4: SQL Server cache (entire DB in memory)

Level 5: SSD cache, active after SQL warm‑up

Deployment Process

Five deployments per day are performed via automated scripts (Puppet/DSC). Deployment steps include notifying HAProxy, gracefully draining IIS requests, stopping the site, copying files with Robocopy, restarting the site, and re‑enabling HAProxy.

Team and Collaboration

5 SREs, 6‑7 core developers for Q&A sites, 6 for mobile, 7 for Careers

Strong DevOps integration, remote‑first work culture

Testing and Monitoring

Rapid iteration with minimal unit tests due to static code and active community feedback

Log aggregation via Logstash‑style syslog to SQL, Opserver and Realog for metrics

Cloud Perspective

The team avoids public cloud, citing higher cost and potential performance limits; they prefer vertically scaling on owned hardware.

Performance Focus

Home page load time is kept under 50 ms (currently ~28 ms). CPU utilization stays between 5%–15% on web servers and 5%–10% on database servers, leaving ample headroom for scaling.

Key Takeaways

Mix Windows and Linux where each excels (IIS on Windows, Redis on *nix).

Vertical scaling can be cost‑effective when hardware is cheap.

SSD‑first storage eliminates latency.

Understand read/write patterns to size hardware appropriately.

Efficient code reduces hardware requirements.

Custom tag engine enables complex queries without over‑loading the database.

Focus on necessary work; avoid over‑engineering.

Leverage low‑level optimizations (IL, query plans, memory dumps).

Adopt tools that reduce friction (modern IDEs, VS updates).

Garbage‑collection‑aware programming yields high performance.