Section 10: Seven Ways to Break a Search Box - Interviewer Deep-Dive Challenges

Executive Summary: The design is on the board: a ~20 GB radix trie with top-15 lists at every node, replicated to 40 nodes, fronted by a CDN, fed by a daily build and a one-minute trending delta. Now the interviewer hunts for seams. Each of seven challenges gets the probe, the real question, and an answer with a mechanism, a number and a trade-off. Two answers are "not on day one, and here is the door I left open", and saying so plainly is part of the test.

Challenge 1: The Hammered Prefix

"Every user on Earth types a first. Isn't that a hot key that melts a node?"

What they're really asking: do you know where skew actually hurts in this design?

Model answer: a is the cheapest request we serve. Its answer is a precomputed top-15 list on one node of Section 8's prefix index: a one-character walk. And it almost never reaches us. With a 120 s edge TTL, each edge location fetches a about once per two minutes per cache key (prefix, locale, client, safe-search, index version), so one-letter prefixes hit close to 100% while the blended rate is 60%. And because we replicate rather than shard (D2), there is no "a-shard": all 40 nodes can answer it.

Key Insight: Skew is only dangerous when the hot key lives in one place. Precomputing, edge caching and replication turn the hottest key into the cheapest one. Sharding by prefix range would have made a a problem; if growth ever forces it, the hot ranges get extra replicas.

Quick check before moving on: