Search intent this article targets

This topic targets long-tail searches like "frontend system design search autocomplete", "debounce vs throttle search input", "React search pagination caching", and "autocomplete accessibility frontend interview". These are high-value searches because they combine interview preparation with production implementation.

• Frontend interview candidates preparing system design rounds.
• React developers building real search UIs.
• Product engineers improving perceived speed.
• Teams trying to avoid overfetching and stale results.

Start with requirements

A senior engineer does not start with code. They clarify behavior. What data is searched? Should results update while typing or only after submit? Is the content public and crawlable? Should filters sync with the URL? How large is the dataset? Are results personalized?

• Public SEO search page: URL-driven, crawlable, server-renderable where possible.
• Admin search table: fast filters, authenticated, less SEO concern.
• Autocomplete: low latency, keyboard accessible, request cancellation required.
• Analytics-heavy search: caching and tracking should not slow input responsiveness.

Debounce versus throttle

Debounce waits until the user stops typing for a short delay. Throttle allows one call per fixed interval. Search inputs usually use debounce because you want the final query, not every keystroke.

function debounce(fn, delay) {
  let timerId;

  return (...args) => {
    clearTimeout(timerId);
    timerId = setTimeout(() => fn(...args), delay);
  };
}

const search = debounce((query) => {
  fetchResults(query);
}, 300);

Use throttle for scroll, resize, and drag-style events where updates should happen regularly while the interaction continues.

Cancel stale requests

A common search bug happens when an older, slower request finishes after a newer request and overwrites the UI with stale results. AbortController prevents wasting work and reduces this risk.

let controller;

async function fetchResults(query) {
  controller?.abort();
  controller = new AbortController();

  const response = await fetch('/api/search?q=' + encodeURIComponent(query), {
    signal: controller.signal,
  });

  return response.json();
}

In React, this logic often lives inside a hook that tracks loading, error, results, and the active request.

Cache what users repeat

Users often type forward and backward through the same queries. Caching recent query results makes the UI feel faster and reduces backend load. The cache should have a size limit and a freshness rule.

const cache = new Map();

function getCacheKey({ query, filters, page }) {
  return JSON.stringify({ query, filters, page });
}

function remember(key, value) {
  cache.set(key, { value, createdAt: Date.now() });

  if (cache.size > 50) {
    const oldestKey = cache.keys().next().value;
    cache.delete(oldestKey);
  }
}

Cache public results longer than personalized results. Never share user-specific cached results across users unless the backend explicitly scopes them.

Pagination, infinite scroll, and URL design

Pagination is better for search results that users may revisit, share, or crawl. Infinite scroll is better for discovery feeds where continuous browsing matters more than precise location. URL state is important when users expect back button support or shareable links.

• Use query params for searchable state: ?q=react&page=2&tag=hooks.
• Use stable cursors for large or frequently changing datasets.
• Keep page size predictable and document maximum limits.
• Preload the next page only when it improves real user experience.

Accessibility and keyboard behavior

Autocomplete must work with keyboard and screen readers. That means visible focus, arrow key navigation, Escape to close, Enter to select, aria-expanded, aria-controls, aria-activedescendant, and readable status updates when results change.

• Do not trap focus unexpectedly.
• Do not make hover the only way to select a suggestion.
• Announce loading and result count when appropriate.
• Keep touch targets large enough for mobile.

Interview explanation

A strong frontend system design answer starts with requirements, then discusses debouncing input, cancelling stale requests, caching repeated queries, choosing pagination or infinite scroll based on user intent, syncing URL state when needed, and protecting accessibility. It also mentions backend constraints such as index design and rate limits.

Quick FAQ

Should search always debounce?

Live search usually benefits from debounce. Submit-based search may not need it. Scroll and resize behavior often uses throttle instead.

Is infinite scroll bad for SEO?

Infinite scroll can be weak for SEO if content is not available through crawlable URLs. Public searchable content often works better with paginated URLs.

Where should filtering happen?

Small local datasets can filter in the browser. Large, secured, or indexed datasets should filter on the backend with clear query parameters.

Official references

• web.dev: Optimize INP
• WAI-ARIA Authoring Practices: Combobox