Katkat
Back

Design a Shopping Search Bar with Autocomplete

eBaySoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Tests candidate's ability to design a dual-path search system that separates low-latency typeahead suggestions from heavy, filtered e-commerce catalog search at scale.

Product Scenario

Design the search bar subsystem for a large e-commerce marketplace like eBay. The system must support two key flows:

  1. Typeahead Autocomplete: As a user types in the search box, the system returns instant query suggestions along with matching categories within milliseconds.
  2. Catalog Search & Filtering: Once the user submits a query, the system returns ranked product listings with support for facet filtering (e.g., price, condition, category), sorting, and pagination.

Requirements

Functional Requirements

  • Provide top 5–10 query and category suggestions as the user types (prefix matching).
  • Execute full-text product search with filtering (price, item condition, seller rating, category) and pagination.
  • Reflect inventory changes promptly (e.g., out-of-stock or sold items should not rank high or appear in suggestions).
  • Track user engagement metrics to improve suggestion and search relevance.

Non-Functional Requirements

  • Latency: Autocomplete p99 < 30 ms; full search p99 < 150 ms.
  • Scale: 500 million active listings, 50 million daily active users (DAU).
  • Query Volume: 20,000 queries per second (QPS) for full search, peaking at 100,000 QPS for autocomplete keystrokes.
  • Availability: 99.99% uptime.

Key Discussion Points

Your design should address:

  1. Dual Architecture Paths: Compare the trade-offs of serving autocomplete via in-memory weighted tries versus search cluster solutions (e.g., Elasticsearch completion suggester).
  2. Data Pipeline & Indexing: How search indices and autocomplete dictionaries are updated both offline (batch aggregations of click/purchase logs) and in near real-time (item sales, deletions).
  3. Hot Prefixes & Caching: Multi-tier caching strategy (browser, CDN, edge, Redis) for common prefixes (iph..., vint...) to offload traffic.
  4. Pagination & Consistency: Deep pagination strategies (cursor vs. offset) and handling listings sold while a user browses.
  5. Quality & Guardrails: Techniques to filter offensive queries, suppress zero-result suggestions, and evaluate ranking quality (e.g., Mean Reciprocal Rank, CTR).

Hints

Hint 1

Separate the autocomplete path (query-to-query or query-to-category) from the full catalog search path (query-to-listings) to decouple SLAs.

Hint 2

Evaluate an in-memory prefix trie service partitioned by prefix hash versus an Elasticsearch cluster using completion suggesters for memory and update trade-offs.

Hint 3

Use edge or CDN caching for short prefixes (1-3 characters) where suggestion results are virtually identical across users.

Follow-up questions

  • How would you incorporate user personalization (e.g., past purchases, preferred categories, geographic shipping distance) without destroying cache hit rates for autocomplete?
  • If a sudden viral trend causes a new search term to explode, how does your ingestion pipeline surface it in autocomplete within minutes rather than waiting for an offline batch rebuild?
  • How do you implement deep pagination efficiently across distributed search shards without suffering the high memory cost of large `from + size` offsets?