Typeahead Autocomplete – System Design Interview Preparation

Practice designing an autocomplete system. Cover trie data structure, ranking algorithms, and low-latency responses.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Typeahead design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Typeahead is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Returning ranked suggestions in under 100ms for a prefix the user is still typing, which means the answers are precomputed, not searched.

Scale to establish before drawing anything

A query fires on every keystroke, so request volume is several times the search volume behind it.
Latency budget is about 100ms end to end, including network - there is no time for a scan.
The vocabulary is large but the useful prefix set is bounded, which is what makes caching work.

Core components

Trie or FST – Prefix structure with the top-k completions stored at each node - precomputed, not computed per request.
Ranking data – Query frequency, recency and personalisation signals, aggregated offline.
Aggregation pipeline – Builds the ranked structure periodically from the query log.
Serving layer – In-memory, sharded by prefix, with aggressive client and edge caching.
Query logger – Feeds the next build. The loop that keeps suggestions current.

Trade-offs to defend

Top-k at each node – Storing the answers at build time is what makes the read a lookup instead of a traversal. It costs memory and is the whole design.
Rebuild cadence – Hourly rebuilds miss breaking news; continuous updates make the structure mutable and much harder. Many systems run both paths.
Personalisation – Per-user suggestions break the shared cache that makes this cheap. Usually a small personalised overlay on a shared base.

Follow-up questions to expect

A term becomes popular in minutes. How long until it appears, and what would it take to halve that?
A user types eight characters. How many requests, and what does the client do to reduce them?
How do you keep offensive or unsafe completions out, and where in the pipeline?