Search autocomplete (typeahead)

Aggregate query logs offline into counts per query, weighted toward recent and converting searches. Build a trie where each node stores its top-k completions, shard it by prefix, and serve it from memory behind an edge cache for short, hot prefixes. The client debounces input. Personal history and trending queries are blended in at request time.

Clients send debounced prefix requests to a suggestion service that reads precomputed top-k suggestions from an in-memory trie or prefix map, sharded by prefix and replicated. Offline pipelines aggregate search logs to rebuild the index regularly, while a streaming path adds trending queries between rebuilds. Responses are cached at the CDN and in the browser.

Combine query popularity (with time decay), recent trends, personal history, location and language, business signals such as product availability, and filters for unsafe or low-quality queries. Weights are tuned with click-through data and A/B tests.

Precompute top-k per prefix so lookups are O(prefix length), keep the index in memory close to users, cache popular prefixes at the CDN, debounce on the client, cancel stale requests, and return small payloads.

Without it, each request must traverse the whole subtree under the prefix and sort, which is slow for short prefixes with millions of completions. Precomputing top-k makes every lookup proportional to the prefix length, at the cost of extra memory and a rebuild step.

Add fuzzy matching with edit distance for short prefixes, keep a spell-correction dictionary from search logs (queries users corrected), and use phonetic or n-gram indexes; limit fuzziness for performance.

Blend global suggestions with the user's recent searches and inferred interests at query time, stored per user in a fast store, with privacy controls to clear history.

Shard by prefix ranges (with care, since 's' is far bigger than 'x') or by hash of the first characters, rebalance using measured traffic, and replicate each shard for availability and read throughput.

Maintain block lists, run classifiers on candidate queries during index builds, apply legal removals quickly through an override list checked at serving time, and monitor reports.

A batch job aggregates search logs over a window, normalises queries, counts frequencies with decay, applies filters, builds the trie with top-k lists per node, and ships the snapshot to servers that load it with a hot swap.

Normalise text per language (case, accents, scripts), tokenise appropriately (CJK has no spaces), build separate indexes per locale and choose by user language, and support transliteration such as Hinglish to Hindi.

Autocomplete predicts queries from a prefix with tight latency budgets and small result sets, often from precomputed data. Full search retrieves and ranks documents for a complete query with richer relevance models.

Store at each node a small precomputed list of the top K completions beneath it with their scores, so a lookup walks to the prefix node and returns that list without exploring the subtree. Rebuild these lists offline when counts change.

Fetch top candidates by global score, then re-rank a short list with features such as the user's recent searches, location, language and time of day, using a lightweight model or weighted formula that runs in a few milliseconds.

Run a small real-time layer: count recent queries in a sliding window (a stream processor or Redis sorted sets) and merge those with the static trie results at request time.

Debounce input (around 100–300 ms), cache results per prefix in memory, cancel in-flight requests when the user types more, prefetch on focus, and render keyboard-accessible listboxes.

Measure suggestion click-through rate, keystrokes saved, mean reciprocal rank of the chosen suggestion, zero-suggestion rate and latency, and run A/B tests for ranking changes.

A streaming job counts queries in short windows, detects spikes compared with baselines, and pushes trending entries to a small fast-update layer merged with the main index at serving time.

At scale, it is too slow and expensive under heavy keystroke traffic, cannot rank by popularity efficiently and hurts the primary database. A dedicated in-memory index is designed for this access pattern.

Use completion suggesters (FST-based, very fast prefix lookup) or edge n-gram analysers with search-as-you-type fields, weighting suggestions by popularity; good for product catalogues of moderate size.

Use the combobox pattern: an input with role="combobox", aria-expanded, aria-controls and aria-activedescendant, a listbox of options, arrow-key navigation, Enter to select and Escape to close.

The trending layer boosts it based on recent velocity rather than total count, with safety filters, so it appears within minutes rather than after the next batch rebuild.

If you keep 10 million popular queries averaging 25 bytes with top-k lists of IDs at each node, the index fits in tens of gigabytes, so it can live in memory on each replica.

Index entity names, aliases and popular attributes, rank by entity popularity and availability, return rich results with type, image and ID, and navigate directly to the entity page when one is chosen instead of running a search.

Serve precomputed results for all one- and two-character prefixes from cache or the edge, since they are few and very popular, and consider waiting for two characters before showing suggestions to reduce noise.

Use a two-tier design: a large index rebuilt daily or hourly, plus a small real-time index fed by a stream of recent queries. Merge results from both at query time with a recency boost.

Only suggest items the user may see, by filtering on access lists in the index or per-tenant indices, never leak private titles through global popularity, and re-check access when the suggestion is opened.

Rate-limit per client, ignore bot traffic in log aggregation, require minimum distinct users before a query can be suggested, and filter manipulation attempts.

Load the new snapshot on a canary, compare suggestions and latency with the old one, then hot-swap across the fleet with the ability to roll back instantly.

The suggestion text, a highlight range for the matched prefix, a type (query, product, category), optional thumbnail or metadata, and an ID for click logging.

Strip or hash personal data, require a minimum number of users per query before suggesting it, keep retention limited, and let users clear personal history.

Instrument the client to record time from keystroke to suggestions rendered, include network and rendering time, report p50 and p95 by region and device, and track abandoned responses that arrive after a newer keystroke.

1. ABinary heap
2. BBloom filter
3. CHash map
4. DTrieCorrect answer

Why: A trie stores strings by shared prefixes, so all completions of a prefix are under one node.

1. AScanning the database
2. BSorting on every request
3. CFull-text search per keystroke
4. DPrecomputed top-k lists in a trieCorrect answer

Why: Lookup cost depends on prefix length.

1. ARandom order
2. BQuery length only
3. CRecency, personalisation and contextCorrect answer
4. DAlphabetical order only

Why: Many signals combined.

1. AClearing caches
2. BA streaming fast-update layerCorrect answer
3. CWaiting for the batch job
4. DManual edits

Why: Merged at serving time.

1. ATo sort results
2. BTo cache the trie locally
3. CTo encrypt the query
4. DTo avoid sending a request for every single keypressCorrect answer

Why: Waiting briefly after typing cuts request volume a lot with no visible delay.

1. ATries cannot be sharded
2. BIt slows writes
3. CPrefixes have very uneven trafficCorrect answer
4. DPrefixes are encrypted

Why: Some letters are far busier.

1. ASnapshot API
2. BCompletion suggesterCorrect answer
3. CPercolator
4. DScroll API

Why: FST-based and very fast.

1. AWait for the next rebuild
2. BDelete logs
3. CRestart servers
4. DAn override block list at serving timeCorrect answer

Why: Legal removals cannot wait.

1. AClick-through rate and keystrokes savedCorrect answer
2. BIndex size
3. CCPU usage
4. DNumber of shards

Why: Pair these with latency metrics.

1. AQueue all requests
2. BReload the page
3. CBlock typing
4. DCancel stale in-flight requestsCorrect answer

Why: Only the latest prefix matters.

1. AMenu bar
2. BTree
3. CCombobox with a listboxCorrect answer
4. DTablist

Why: Arrow keys move through options.

1. AProportional to the prefix lengthCorrect answer
2. BProportional to the whole subtree
3. CRequire a database join
4. DSlower

Why: The answer is stored at the prefix node.

1. AOnly offensive suggestions
2. BServer logs
3. CA short list of global top candidatesCorrect answer
4. DEvery possible completion

Why: A small list keeps re-ranking fast.

1. ARandom sampling
2. BAggregated query logs and clicksCorrect answer
3. CThe product catalogue's alphabetical order
4. DManual editing only

Why: Real searches, clicks and orders show which completions people actually want.

1. ACache size
2. BEdit distanceCorrect answer
3. CQuery length
4. DServer location

Why: Limit fuzziness for speed.

1. AIt is not valid SQL
2. BIt returns nothing
3. CIt needs Redis
4. DToo slow and costly at keystroke volumeCorrect answer

Why: Use a dedicated index.

1. AOnly spaces
2. BOnly numbers
3. COnly emojis
4. DCase, accents and scriptsCorrect answer

Why: Each language needs its own rules.

1. AOnce a year
2. BHot swap after a canary checkCorrect answer
3. CEdit in place on every server
4. DDelete then rebuild live

Why: Rollback stays instant.

1. AFor caching
2. BPrivacy and manipulation resistanceCorrect answer
3. CTo save memory
4. DTo speed up tries

Why: One user's query is not a trend.

1. A0 ms always
2. B1 minute
3. CAbout 100–300 msCorrect answer
4. D5 seconds

Why: Balances speed and load.

1. ABe permanent
2. BBe shared with advertisers
3. CBe clearable by the userCorrect answer
4. DBe public

Why: Privacy controls matter.

1. AHaving no ranking
2. BRunning offline only
3. CTighter latency and precomputed resultsCorrect answer
4. DRanking documents deeply

Why: Prefix prediction is lighter.

1. AManual curation
2. BBrowser caching
3. CA small real-time index merged with the main oneCorrect answer
4. DA weekly full rebuild only

Why: The two-tier design balances freshness and cost.

1. APrecomputed cached resultsCorrect answer
2. BA full scan per request
3. CThe user's history only
4. DNothing

Why: There are few of them and they are very hot.

1. AOnly plain text
2. BThe raw query log
3. CSearch results pages
4. DType, ID and image so the app can navigate directlyCorrect answer

Why: Picking an entity goes straight to it.

1. AIgnore tenants
2. BBe cached globally per prefix
3. CInclude only items the user may accessCorrect answer
4. DShow every popular title

Why: Suggestions can leak private names.

1. AThe user's password
2. BThe full index
3. CServer logs
4. DAn ID for click loggingCorrect answer

Why: Clicks train ranking.

1. ASplitting on spaces
2. BRemoving characters
3. CUppercasing
4. DLanguage-specific tokenisationCorrect answer

Why: Scripts differ in word boundaries.

1. AIts length
2. BAlphabetical order
3. CRandom chance
4. DRecent velocity rather than total countCorrect answer

Why: This is how trending detection works.

1. ACounted twice
2. BPromoted
3. CIgnored only on weekends
4. DExcluded from aggregationCorrect answer

Why: Bot traffic skews popularity counts.

1. AOnly in the database
2. BNowhere
3. CIn email
4. DAt the CDN and in the browserCorrect answer

Why: Short TTLs keep them fresh.

1. ABy the number of shards
2. BFrom keystroke to rendered suggestions on the clientCorrect answer
3. COnly inside the index server
4. DBy CPU usage

Why: Users feel network and rendering time too.