System Design Interview
Search that understands meaning, not just keywords, inspired by Shopify and Etsy: product text turned into embeddings by background workers, a vector index searched by nearest neighbour and keyword together, and popular queries served from a cache. A teaching design.
See why comparing the query with every product can't scale.
What was missing: Nothing yet.
Why that's risky: Every search reads 10M vectors. The database melts long before peak.
What gets added: One server that embeds the query, then reads every product embedding from the database and compares them one by one.
Trade-offs: No new components, but no way to search millions of vectors quickly.
Find the nearest products without scanning them all.
What was missing: Every search scanned every product.
Why that's risky: Sellers wait for the embedding call on every save, and a bulk import hammers the embedding model.
What gets added: A vector index that finds approximate nearest neighbours in milliseconds (HNSW graphs), holding each product's embedding and keywords so meaning and exact matches are searched together.
Trade-offs: Approximate search can miss a close match; tune it for 95%+ recall.
Keep catalog updates fast and absorb bulk imports.
What was missing: Catalog saves waited on the embedding model, and bulk imports overloaded it.
Why that's risky: A product is searchable a few seconds after it is saved, not instantly.
What gets added: Saving a product only writes the database and drops an event on a queue; embedding workers read the product, embed it and update the index at their own pace.
Trade-offs: Eventual consistency between the catalog and the index; price and stock are read fresh at display time.
Serve popular searches without touching the index.
What was missing: Every search paid for an embedding call and an index lookup, even the same query a thousand times a minute.
Why that's risky: Cached results can show a product that just sold out; check stock when rendering.
What gets added: A cache of results and embeddings for popular queries; about 70% of searches end there.
Trade-offs: Short TTLs keep results fresh but lower the hit rate.
Stop scrapers and remove single points of failure.
What was missing: Scrapers could crawl the whole catalog through search, and the load balancer and database were single points of failure.
Why that's risky: Aggressive limits can block shoppers behind a shared office IP.
What gets added: A rate limiter, a second load balancer, a database replica, more search and embedding capacity, and monitoring of zero-result searches and click-through to judge quality.
Trade-offs: Click-through is the real quality signal; offline relevance tests alone mislead.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
