Estimate Search Engine QPS

Problem

Estimate the query rate a web search engine at Google scale must serve, in queries per second. Give the daily average and a peak figure, and then extend the estimate one level down: how many backend requests per second does that imply for the index-serving tier, if each user query fans out to every shard of a partitioned index?

State each assumption, show each multiplication, and finish with an order-of-magnitude answer you would be comfortable planning capacity against.

• Count only web search queries, not ads, maps, or image search.
• Treat a "query" as one user-submitted search; autocomplete keystrokes are a follow-up.
• Answer in powers of ten first, then a rounded number.

Examples

Inputs you can state and defend without being an insider:

• Users: roughly 4-5 billion people use web search in a month; Google's share of that is dominant, so ~4 × 10^9 monthly searchers is fine.
• Queries per user: a few per day on average. Heavy users run dozens; many people search once or twice. 2-3 per user per day is a reasonable blended figure.
• Daily-to-peak ratio: traffic is not flat. Searches follow the sun across time zones, so global traffic is smoother than a single-country service, but a peak-to-average ratio of 2× is standard and 3× is conservative.
• Index partitioning: the web index is far too large for one machine. Accepting "on the order of 1,000 shards" is fine; the exact number does not matter, the fan-out structure does.
• Retries and replicas: each shard is replicated for throughput and availability; a query hits one replica per shard.

Hints

1. Start with people, not with queries: a number of users times a number of queries each is easier to defend than pulling a query count out of the air.
2. A day has 86,400 seconds. Rounding it to 10^5 makes per-second division trivial and costs you only 15%.
3. Fan-out is multiplicative. If a query touches every shard, the backend QPS is user QPS times shard count, and that product is usually the number that actually decides how many machines you need.