Section 2: Stale Is Fine, Harmful Is Not - Requirements (Functional & Non-Functional)

Executive Summary: This section turns Section 1's assumptions into a contract: seven functional requirements, four explicit exclusions, and a non-functional half that puts a number on latency, availability, scale, freshness, takedowns and privacy. One asymmetry ties them together: a stale suggestion is acceptable, an offensive or private one is not.

The interviewer nods at the whiteboard. "Fine. What are we actually promising?" "Suggestions should feel instant" is a wish. "Ninety-nine percent of suggestion requests render within 100 ms of being sent" is a promise. And here the most important promises aren't about speed. They're about what the platform is willing to say.

The Functional Contract

Seven requirements, each traceable to a part of the design:

1. Top-10 completions per prefix. Return up to ten full queries that start with what's typed, ranked by likelihood. For Maya's chicago mara: "chicago marathon 2026", "chicago marathon route", and so on. Prefix match on the start of the query only; mid-string matching is a Section 10 challenge.
2. Per-locale results. Every request carries one locale (en-US). Suggestions come from that locale's queries, so a Chicago user and a Lyon user typing ch see different lists.
3. Safe-search aware. If safe search is on, explicit completions are excluded. This becomes part of the cache key in Section 4, not a per-user lookup.
4. Recent personal history for signed-in users. Maya searched "chicago marathon bib pickup" yesterday, so it should appear first, marked as history. Users can delete one entry or clear it all.
5. Trending queries. "chicago marathon results" isn't in yesterday's base index. It spiked this morning and must be suggestable while it still matters.
6. Removal on request. A suggestion that breaks policy or a court order must disappear everywhere, quickly, without waiting for a rebuild.
7. Logging to learn from. Every submitted search and every selected suggestion is logged. That log is the only input to tomorrow's index.

The interviewer pokes at the last one: "Why not log every keystroke too? More data." Because keystroke prefixes aren't queries: count them and chicago mar becomes a "popular query" in its own right. We rank on submitted searches and suggestion selections, never raw keystrokes (D8). Once there's enough selection data, ranking flips to a learned model (Section 12).

Quick check before moving on: