210k/s
suggestion requests at the evening peak
Assume six requests per search. A billion searches a day become 69,000 requests a second, 210k at peak, and a cricket final can double it.
Search per keystroke, or look it up?
Bad: Query the database
LIKE 's%' reads and sorts 8M rows: seconds per request.
Good: Precompute every answer
Build offline. Serving is one lookup in RAM: microseconds.
Store the answer at every trie node
Walk to “iph”, read the stored list, microseconds. A radix trie in flat arrays fits 100M queries in about 10 GB, so every server holds a copy.
Popularity should favour recent days. Rereading 30 days of logs every night means 9 TB.
The trick
One decayed score per query: score × 2^(−Δt / half-life) + new count. Each hourly run reads one hour.
7:00 pm, the toss. The hourly index hasn’t heard.
A stream job counts one-minute windows with sketches and ships about 20,000 risers every minute. Each list takes at most two.
Keep the user out of the URL, and caches answer
Same URL, same bytes for everyone in a bucket. The browser and CDN answer over 40% of requests; your history merges on the phone.
Four guards on every suggestion
- Require 20+ distinct searchers
- Apply block rules at build time
- Push urgent blocks within 60 s
- Store 12, show 10; purge the CDN
Remember
Precompute everything: an hourly trie with top completions at every node, a trending list every minute, caches at every layer, history on the device, blocks at both ends.