Design product search for an online store

For this problem, we'll design keyword search over a large catalogue: query understanding, retrieval, ranking, facets and pagination, plus the part most candidates rush, keeping the index in step with the product database. Interviewers like it because it sounds like "put Elasticsearch in front of it" and then quietly tests sync, sharding, relevance and deep paging. Autocomplete lives in Design typeahead, and discovering documents on the open web in Design a web crawler.

01Requirements

Functional requirements

• Users should be able to search products by keywords and still get results when they make a typo ("addidas" finds Adidas).
• Users should be able to filter by category, brand, price range, rating and availability, and see a count next to each filter value.
• Users should be able to sort by relevance (default), price, rating or newest.
• Users should be able to page or scroll through results.
• Users should see current price and stock: a product that sold out should stop showing as available within seconds.

Non-functional requirements

• Scale: a catalogue of about 100 million products (our assumption) and a few thousand searches per second at peak.
• Latency: p99 under 200 ms at the search API. That's our own target, not a standard: mobile networks add their own delay on top, and the results page is the main path to a purchase.
• Freshness: price and stock changes visible in search within about 5 seconds; new products within a minute is fine.
• Availability: search should degrade (slightly stale results, fewer facets) rather than go down. A store with no search is a store with no sales.

At this point, ask your interviewer: how big is the catalogue, and how often do prices and stock change? A 50,000-product shop and a 100-million-product marketplace with flash sales need very different designs.

02Core entities and API

• Product: id, title, description, brand, category path, attributes (size, colour), price, rating, review count, in-stock flag, seller. Lives in Postgres.
• Search document: a flattened, read-optimised copy of a product in the index, with extra signals such as sales in the last 30 days.
• Facet: a filterable field plus value counts for the current query, for example brand: Nike (1,243).
• Cursor: an opaque token that encodes where the next page starts.

GET /v1/search?q=running+shoes
             &filters=brand:nike|adidas;price:2000-5000;rating:4+
             &sort=relevance
             &cursor=eyJzIjpbMTIuNCwiUDk5MSJdfQ
             &limit=24

200 OK
{
  "results": [{ "productId": "P991", "title": "...", "price": 3499, "rating": 4.4, "inStock": true }],
  "facets": { "brand": [{ "value": "Nike", "count": 1243 }], "price": [...] },
  "correctedQuery": null,
  "nextCursor": "eyJzIjpbMTEuOSwiUDQwMiJdfQ"
}

GET /v1/products/{productId}        // product page, served from Postgres plus a cache

Filters travel as one structured parameter the service validates against the facet schema. The API returns a nextCursor instead of taking a page number (see deep dive 4), and correctedQuery lets the UI say "Showing results for adidas".

03Back-of-envelope estimates

Notice three things. The data is small: 200 GB fits on a handful of machines, so storage does not drive the design. Read fan-out drives the design: 48,000 shard queries per second at peak is what decides the replica count. And the write churn, mostly price and stock, is what decides how hard you have to work on freshness.

04High-level design

Let's start with the simplest thing that works, then grow it one requirement at a time.

Step 0: one Postgres box. For a catalogue of up to a few million products, Postgres full-text search is enough: a tsvector column with a GIN index (Postgres's inverted index), ts_rank for ordering, pg_trgm for typos, WHERE for filters and GROUP BY for facet counts. One system, no sync problem. Say this out loud, because it shows you won't reach for a cluster before you need one (Instacart even moved its catalogue search from Elasticsearch to sharded Postgres). It stops being enough for us because we want fuzzy matching, field boosts and many facet counts over 100M rows at thousands of QPS, without competing with checkout traffic.

So we split reads and writes, and the two paths meet at the index.

To support keyword search with typos, we add an Elasticsearch index of search documents. An analyzer lowercases, splits and stems text into terms in an inverted index. At query time we run a multi_match over title, brand and description with fuzziness: AUTO: terms of 1-2 characters must match exactly, 3-5 characters allow one edit and longer terms two, so "addidas" still finds "adidas".

To support filters and facets, we map brand, category and attributes as keyword fields, and price and rating as numbers. Filters go in the filter clause of a bool query: they don't affect the score, and Elasticsearch caches frequently used filters automatically. Facet counts come from aggregations in the same request: a terms aggregation per keyword facet and a range aggregation for price buckets. Here's the shape of one request:

{
  "query": {
    "bool": {
      "must":   [{ "multi_match": { "query": "running shoes", "fields": ["title^3", "brand^2", "description"], "fuzziness": "AUTO" } }],
      "filter": [{ "terms": { "brand": ["nike", "adidas"] } },
                 { "range": { "price": { "gte": 2000, "lte": 5000 } } },
                 { "term":  { "in_stock": true } }]
    }
  },
  "aggs": {
    "brand": { "terms": { "field": "brand", "size": 20 } },
    "price": { "range": { "field": "price", "ranges": [{ "to": 1000 }, { "from": 1000, "to": 3000 }, { "from": 3000 }] } }
  },
  "sort": ["_score", { "product_id": "asc" }],
  "size": 24
}

To support relevance beyond text match, the query service adds business signals (rating, recent sales, stock) on top of the text score. We cover this in the ranking deep dive.

To understand messy queries, the query service runs a small pipeline before it calls the index:

• Normalise: lowercase, trim, unify units ("1tb" and "1 TB").
• Spell correction: check rare terms against a dictionary built from the catalogue and past successful queries, and return correctedQuery when you rewrite.
• Synonyms: expand "tv" to "television" with a search-time synonym list, so you can edit it without reindexing.
• Category prediction: a classifier guesses that "iphone case" means Phone Accessories and boosts that category. Mention it; you don't need to design it.

To keep the index fresh, the catalogue service writes to Postgres only. A CDC connector streams committed changes into Kafka, and an indexer bulk-writes them to Elasticsearch. Deep dive 1 explains why.

To hit the latency target at peak, replicas spread the read load (deep dive 2), and a Redis cache holds result pages for popular queries, keyed by normalised query, filters, sort and cursor, with a 30-60 second TTL. Search traffic is skewed toward head queries ("iphone", "saree", "air fryer"), so a small cache absorbs a big share of reads, and the short TTL caps how stale a cached price can be.

Put together: the query service normalises the request and checks Redis. On a miss it sends one request to Elasticsearch, which retrieves, filters, scores and aggregates across all shards, and returns 24 products, facet counts and a cursor.

05Deep dives

1. Keeping the index in sync with the database

Postgres is the source of truth and the index is a copy. Every price change, stock change and new listing has to reach the copy in order, without loss, and without slowing the seller's write.

Bad: dual writes from the application. The catalogue service updates Postgres and then calls Elasticsearch. In production the second call times out after the first committed, and the database says ₹499 while search shows ₹599. Two concurrent updates can also reach the index in the opposite order. No transaction spans both systems, so there's no clean fix inside the app.

Good: transactional outbox. In the same transaction that updates products, the service inserts a row into an outbox table: {product_id, event_type, payload}. Both commit or neither does. A relay publishes new outbox rows to Kafka, so exactly one write must succeed and everything after it can retry.

Great: outbox read through CDC. Instead of polling the outbox, run a CDC connector such as Debezium, which reads Postgres's logical replication stream and publishes each committed change to Kafka. Key messages by product_id so all changes for one product stay in order in one partition. Two details make it robust:

• Versioned, idempotent writes. The indexer writes each document with its database version (a version column or updated_at) as the Elasticsearch external version, so a replayed or late event can never roll a product backwards.
• Rebuilds without downtime. When the mapping changes, build a new index from a snapshot plus the Kafka stream, then flip an alias from products_v7 to products_v8. Readers always query the alias.

Why an outbox rather than streaming raw table rows? Raw rows tie every consumer to your table schema, while an outbox event (ProductPriceChanged) is a deliberate contract, and Debezium can route outbox rows directly. I'd default to outbox table plus Debezium plus Kafka.

The consistency lag, explained. Search is eventually consistent. A change goes: commit, CDC reads it from the log, Kafka, an indexer batch (say we flush every second or every 1,000 docs), then an Elasticsearch refresh, which by default makes writes searchable within 1 second. In normal operation the index trails the database by roughly a few seconds, inside our 5-second target. During a backlog it can be minutes, so alert on consumer lag. The rule that keeps this safe: search may be slightly stale, checkout never is. Cart and checkout read price and stock from Postgres, not the index.

Freshness for price and stock. These fields change far more often than titles. Three options:

• Partial updates (_update with only price). Easy, but Elasticsearch still reindexes the whole document internally, so a flash sale that changes 1M prices costs 1M reindexes.
• Coalesce in the indexer: keep only the latest change per product within a short window, so 20 stock ticks become one write. This is my default.
• Index only a price band and an in_stock flag for filtering, and fetch the exact live price for the 24 shown products from a price cache at render time. One extra lookup per page buys an always-current price.

2. Sharding and replicas for scale

An Elasticsearch index is split into primary shards, and each document lands on one of them by hashing its routing value (by default the document ID) modulo the number of primaries. Every shard is a self-contained Lucene index.

A product search does not know which shard holds the matching products, so it must ask all of them. This is scatter-gather: a coordinating node sends the query to one copy of every shard, each returns its own top 24 IDs and scores, and the coordinator merges them into a global top 24, then fetches only those documents.

Two consequences follow. One slow shard makes the whole query slow, so keep shards similar in size. And more shards is not free: each is another sub-query per search, so 100 tiny shards for 200 GB is worse than 8 healthy ones.

Shard sizing. Elastic's guidance is roughly 10-50 GB per shard and under 200M documents per shard. With about 200 GB of index, 8 primaries puts each near 25 GB with room to grow. The primary count is fixed when you create the index; to change it you use the split API or reindex into a new index behind an alias. Plan for 2-3 years of growth up front.

Replicas for read throughput. Every replica is a full copy of a shard that can serve searches, and by default Elasticsearch picks among copies with adaptive replica selection, which aims to cut latency. Replicas also give you failover.

What about routing by category? It lets a query scoped to "Shoes" hit one shard, but categories are badly skewed (Electronics dwarfs Stamps), so you get hot shards, and unscoped queries still fan out. Start with default ID routing.

One gotcha with facets. A terms aggregation also runs as scatter-gather: each shard returns its top buckets (by default it over-fetches size × 1.5 + 10 per shard), and counts can be slightly approximate for long-tail values. For a store's brand facet that's acceptable; say so if asked.

3. Relevance and ranking

Finding matching products is the easy part. With 40,000 matches for "shoes", the order decides whether anyone buys.

Bad: sort by text score alone. Elasticsearch scores matches with BM25 by default. BM25 rewards rare terms (IDF), gives diminishing returns for repeating a term (term frequency saturates, controlled by k1, default 1.2) and normalises for field length (b, default 0.75). It's a strong first pass, but it knows nothing about commerce: a cheap phone case with "iPhone 15" in the title three times can outrank the iPhone 15.

Good: BM25 plus boosts and business signals. Boost fields (title matters more than description), boost phrase matches, and then blend in signals with a function_score query: average rating weighted by review count, sales in the last 30 days, in-stock status, and the predicted category from query understanding. Use log or saturating functions so a bestseller doesn't bury every relevant newcomer, and keep weights in config so merchandisers can tune them without a deploy.

Great: two-stage ranking with learning to rank. Retrieval stays cheap (BM25 plus filters over millions of candidates). Then re-rank only the top few hundred per shard with a richer model, using Elasticsearch's rescore with a window_size (its docs give 100-500 as a typical range) or a separate ranking service. A learning-to-rank model is trained on clicks, add-to-carts and purchases per query, corrected for position bias (top results get clicked partly for being on top). Slack describes the same two-stage idea: cheap retrieval in Solr, then a learned re-ranker in the application. This is the senior mention; you don't need to design the model.

How do you know it's better? Offline, score labelled query-product pairs with a metric such as NDCG; online, A/B test on conversion per search. My default: BM25 plus boosts plus function_score on day one, log every impression and click, and add learning to rank once there's enough data.

4. Deep pagination

The naive API is page=N, which becomes Elasticsearch from = (N-1) × 24, size = 24. Here's the catch: with scatter-gather, every shard must collect from + size hits and send them to the coordinator, which sorts all of them and throws away everything before from.

Bad: unbounded from/size. Page 400 means each of 8 shards collects about 9,600 hits so the coordinator can keep 24. Elasticsearch blocks this by default: from + size can't exceed 10,000 (the index.max_result_window setting), because deep pages eat memory and CPU on every shard. Raising the limit only hides the problem.

Good: cap the pages. Nobody usefully browses 10,000 shoes one page at a time. Show numbered pages up to a limit (say 50 pages of 24, which stays under 10,000) and nudge people to filter instead. It's a product decision as much as a technical one, so propose it to the interviewer.

Great: cursor with search_after. For infinite scroll, sort by _score plus a unique tie-breaker such as product_id, then pass the sort values of the last hit as search_after for the next page. Each shard only needs results after that point, so page 400 costs about the same as page 2. The API wraps those sort values in the opaque nextCursor. Two subtleties: you can't jump to an arbitrary page, and if the index refreshes between requests the order can shift, so pair search_after with a point in time (PIT) if you need a frozen view, for example in an export job.

I'd default to search_after cursors for the scrolling grid and a capped page count where the design calls for page numbers.

06What interviewers look for

Green flags: you ask about catalogue size and write churn early; you separate retrieval from ranking; you put numbers on shards and replicas; you state the staleness the design accepts.

Red flags: "write to both", the index as the source of truth, page=500 with offsets, "add more shards" as the answer to every latency question, ranking by popularity alone.

07Follow-up questions

What if prices change thousands of times a second during a flash sale?

Coalesce per product in the indexer so only the latest value is written, and keep checkout on the live price. If that still can't keep up, stop indexing the exact price: filter on a price band in Elasticsearch and fetch live prices for the 24 shown products from a price cache.

What if a query returns zero results?

Retry with a looser query: drop the least important filter, or let "most terms" match instead of all. Say so in the UI, and log zero-result queries: they're the best list of missing synonyms and catalogue gaps you'll get.

What if the Elasticsearch cluster goes down?

Replicas across availability zones cover node and zone failures. In a full outage, serve cached head queries and fall back to category browsing from Postgres. The index is a copy, so you rebuild it from Postgres plus Kafka; nothing is lost.

What if you need to add a new searchable field?

Create a new index with the new mapping, backfill from a Postgres snapshot, replay Kafka from that point, compare with shadow queries, then swap the alias. Keep the old index for a one-step rollback.

What if users type "red dress for a beach wedding"?

Keyword matching struggles with intent like this. The next step is hybrid search: add a vector field with text embeddings, run a k-nearest-neighbour query next to BM25, and merge the two rankings. eBay reports running a sharded vector similarity engine over about 1.7 billion listings with under 25 ms for 95% of responses, so this works at marketplace scale, but it's a follow-up, not the base design.

08How to say it in the interview