What this prompt does
This prompt asks the AI to design a search autocomplete system handling [qps] queries per second with sub-[latency_target]ms p99 latency. It covers ten requirements: a data structure choice (trie, inverted index, or [data_structure]), a ranking algorithm weighing frequency, recency, personalization and trending, a data pipeline from [data_sources], fuzzy/typo-tolerant prefix matching, personalization from [personalization_signals], [language_count]-language support, offensive-content filtering, A/B testing, prefix caching, and a real-time plus batch index update pipeline.
The structure works because autocomplete is a latency-first problem — you have a tiny budget per keystroke, so data structure and caching dominate the design. Passing [latency_target] sets the p99 budget that everything must fit inside. The [data_structure] choice (trie versus prefix hash map) drives memory and lookup speed, [personalization_signals] shape how suggestions adapt per user, and [data_sources] define what the ranking model learns from. Splitting real-time and batch index updates keeps fresh trends visible without rebuilding the whole index constantly.
When to use it
- You're building search-as-you-type and need sub-100ms suggestions at scale
- You're choosing between a trie, inverted index, or
[data_structure]for prefixes - You need a ranking design that blends frequency, recency, and personalization
- You want personalization driven by real
[personalization_signals] - You need typo tolerance and
[language_count]-language support - You're designing the index update pipeline so trending terms surface quickly
Example output
Expect a latency-focused design: a data-structure recommendation with memory tradeoffs, a ranking section weighting your signals, a caching strategy for popular prefixes, a data pipeline pulling from [data_sources], a fuzzy-matching approach for typos, and an index-update design splitting real-time and batch paths. It usually includes a latency breakdown showing where the [latency_target] budget is spent and storage estimation.
Pro tips
- Set
[latency_target]aggressively but realistically; it's the constraint that justifies the trie and prefix-caching decisions - Pick
[data_structure]based on memory versus speed; a trie is fast but memory-hungry, a prefix hash map trades some flexibility for footprint - Be specific with
[personalization_signals]— vague signals produce a vague ranking model - Ask for the explicit latency breakdown; it reveals whether your budget is realistic before you build
- Make sure the index-update pipeline covers both fresh trends (real-time) and bulk corrections (batch)
- Don't skip offensive-content filtering; autocomplete surfacing the wrong suggestion is a real reputational risk
