Section 3: The Keystroke Multiplier - Scale Estimation & Workload Analysis

Executive Summary: Five billion searches a day isn't the headline. Each search becomes about eight suggestion requests, so the read path carries 40 billion requests a day, ~460K QPS on average and ~1M at peak, and a 60% CDN hit rate leaves 400K QPS for the origin. The second surprise points the other way. The whole serving index comes to about 20 GB, which fits in one machine's RAM, so we replicate it to every node instead of sharding it. Forty nodes in 4 regions cover the peak even after losing a region.

The requirements from Section 2 are on the board. The interviewer caps the marker. "How big is this thing?"

You: "Inputs first, so you can correct them. Then the step that matters most, how many requests one search becomes, and then the index, which I suspect is smaller than either of us expects."

Daily active searchers           1 billion
Searches per user per day        5
Average submitted query length   20 characters (3-4 words)
Characters typed before submit   ~12
Peak-to-average factor           2

You: "I'll use 5B a day. Google is publicly cited higher, around 8.5B or more. That scales every rate by about 1.7× but changes no decision, and the index size doesn't move at all, because it tracks distinct queries, not traffic."

From Searchers to Searches

Searches/day:   1B users × 5            = 5 billion searches/day
Average rate:   5,000,000,000 ÷ 86,400  = 57,870/s  ≈ 58K searches/s
Peak:           58K × 2                 ≈ 116K searches/s

You: "116K a second is the log-ingestion rate. It isn't the serving load."