34.5 What does the whole system look like?

Step 4: High-level design (10 minutes)

Figure: the final design. The read path is one key lookup; all the counting and ranking happens off to the side.

A keystroke, step by step:

1. The user types "dat". After 100 ms of no typing, the client sends GET /v1/suggest?q=dat.
2. The CDN answers if it has "dat" cached (very common for short prefixes).
3. Otherwise the suggest service reads prefix_suggestions["dat"] from the in-memory prefix store and returns it.
4. When the user presses Enter, the full query goes to search (Chapter 19) and is logged.

Building suggestions:

1. Every search is written to a search log (a Kafka topic, Chapter 22).
2. A daily batch job counts queries over the last weeks and builds top-5 per prefix.
3. A trending stream keeps decayed counts for the last few hours (34.8).
4. A merge + filter step blends them, removes blocked or manipulated queries, adds new book titles, and publishes a new table version. Servers switch to it atomically.

Interviewer pushback:

• "What if the prefix store is down?" → The search box just shows no suggestions; search still works. Suggestions are a convenience, so we fail silently with a short timeout.
• "How do you swap tables without a gap?" → Build the new version under new keys (or a new store), verify it, then flip a version pointer. Rolling back is flipping it back.

Memory code: "Read one key on the hot path; build the keys somewhere else."

---

Offer: "The interesting parts are the data structure, computing top-K per prefix, keeping it fresh with trends, and caching. Which would you like?"