Section 3: Three Hundred Million Readers, One Database - Scale Estimation & Workload Analysis

Executive Summary: 300 million page views a day is 10,500 a second at peak, but the edge cache absorbs 85% of them, the origin bundle cache absorbs 95% of what's left, and the database sees only about 4,000 queries a second. Writes peak at about 400 a second, and 86% of them are votes. The whole corpus is about 1.6 TB with indexes today and about 10 TB in five years. The arithmetic forces four conclusions: this is a caching problem first, sharding is for restore time and blast radius rather than throughput, the data fits on a handful of machines, and the real hot spots are page views and megathreads, not votes.

Section 2's requirements are on the board. The interviewer points at the SLO table. "Which of these numbers actually matters? Size it."

You: "I'll start from the readers, because they're the customer. Push back on any input and the rest moves."

Registered accounts        200M
Daily unique visitors      50M   (10M signed-in = 20%, 40M anonymous = 80%)
Page views per visitor     6
Peak factor                3×    (human traffic, follows the working day)

Reads: From Visitors to Queries per Second

Page views:     50M visitors × 6            = 300M/day
Average:        300,000,000 ÷ 86,400 s      = 3,472   ≈ 3,500/s
Peak:           3,472 × 3                   = 10,416  ≈ 10,500/s

Signed-in 20%:  60M/day                     → peak 2,100/s
Anonymous 80%:  240M/day                    → peak 8,400/s

Interviewer: "So the signed-in users get a different page?"

You: "No. Everyone gets the same HTML from the CDN. My votes, my edit rights and my bookmarks come from a separate small viewer-state call."

Now the funnel. The CDN caches each question page with s-maxage=60, stale-while-revalidate, and an origin shield in front of us.

CDN hit ratio target:     85%
Origin renders (peak):    10,500 × 0.15   = 1,575  ≈ 1,600/s   (average ≈ 525/s)
Bundle cache hit ratio:   95%
Bundle rebuilds (peak):   1,600 × 0.05    = 80/s from the database

Interviewer: "Why only 85%? I'd expect 99%."

You: "The long tail. We have 60M questions, and a reader in Lagos who searched an error message lands on one that nobody else opened this minute. A 60-second TTL can't help a page that gets one view an hour. Popular pages hit nearly 100%; the tail drags the average to 85%."

The bundle cache hits where the CDN missed because it has no TTL. A question stays in it until LRU evicts it, and the 150 GB working set covers every question viewed in the last 30 days, while an edge copy lives 60 seconds.

Every origin render still needs live scores, which the bundle deliberately doesn't hold (Section 7 explains why). Database load at peak:

Score lookups:          one per origin render          ≈ 1,600/s
Viewer-state calls:     one per signed-in page view    ≈ 2,100/s   (700/s average)
Bundle rebuilds:        80/s × ~4 queries              ≈ 320/s
                                                         --------
DB reads at peak:       1,600 + 2,100 + 320            ≈ 4,000 queries/s

Spread over the read replicas of 2 clusters, that's comfortable.

Key Insight: Without the CDN, the origin would render 10,500 pages a second. Without the bundle cache, it would rebuild 1,600 a second from the database. With both, the database rebuilds 80 pages a second. The two caches cut full rebuilds by more than 100×, and that ratio is the design.

Search is a separate stream: 20M queries/day ÷ 86,400 = 231 ≈ 230/s average, about 700/s peak. Duplicate suggestions on the ask page add about 1M/day, roughly 12/s, which is negligible.

Quick check before moving on: