Designing a Search-as-You-Type / Autocomplete System

The plain-language idea

The prompt: "Design the frontend architecture for a search-as-you-type autocomplete box" — the user types, and matching suggestions appear within a keystroke or two, without the UI feeling laggy or showing the wrong results. It looks like a small feature, but a strong answer has to name three separate problems and solve each one:

• Don't fire a request on every keystroke. Debouncing the input (waiting for a short pause in typing before firing the request) is the standard fix here — this track assumes the debounce pattern itself is already familiar and won't re-explain it, since it's covered in depth in the Web Performance track.
• Don't let an out-of-order response corrupt the UI. This is the genuinely subtle bug in this prompt, and it's covered below.
• Don't refetch what was already fetched. A small local cache of recent query-to-results pairs avoids redundant network calls for a query the user already typed once, like backspacing and retyping the same letters.

See it in a real thing: the race condition that isn't obvious until it bites you

Say a user types "rea", pauses just long enough to fire a debounced request, then keeps typing "reac" before the first request has resolved. Two requests are now in flight: one for "rea", one for "reac". Networks don't guarantee response order — it's entirely possible for the "rea" request, despite being sent first, to resolve after the "reac" request because of ordinary network jitter.

If the response handler naively does "whatever comes back, render it," the UI can show results for "rea" after the user has already typed "reac" and is looking at newer, faster results — an older, less relevant response silently overwriting a newer, more relevant one. This is a real, common bug class, not a hypothetical edge case: it happens whenever multiple requests for the same evolving input can be in flight at once.

The fix is tracking which request is the current one and discarding any response that isn't it — commonly done by stamping each outgoing request with an incrementing id or the query string itself, then checking on response arrival: "is this response for the query that's still active?" If not, the response is thrown away, even though the network call completed successfully.

A small local cache, keyed by the exact query string, closes the third gap: if a user types "reac", backspaces to "rea", then retypes "reac", the second "reac" request doesn't need to hit the network again if the first result set is still in the cache. This also happens to make the stale-response problem rarer in practice, since a cache hit resolves synchronously and never races anything.

What people usually miss

Watch out

• The race condition is the actual system design signal in this prompt, not debouncing. Debouncing is table stakes and gets named quickly; candidates who stop there without addressing out-of-order responses have covered the easy 80% and skipped the interesting 20%.
• "The network could fail" and "the network could respond out of order" are different problems. A retry-on-failure story doesn't address stale responses at all — the responses here all succeed, just in the wrong order.
• A per-query cache is a small addition with a real payoff, cutting both latency and redundant load for the very common case of a user editing and re-editing the same partial query.
• Keyboard accessibility is a real requirement for this component, not an afterthought — a search-as-you-type UI needs to be fully operable without a mouse. The specific ARIA combobox pattern for wiring that up correctly belongs to the Accessibility track; this lesson's job is naming it as a requirement, not implementing it.

Why this matters in interviews

"Design an autocomplete box" is asked specifically to see whether a candidate reaches past the obvious debounce answer to the request-ordering bug underneath it — that's the detail that separates a surface-level answer from one that shows real production experience with this exact component.