System designMedium~16 min

Interview question

Design search and filtering for a product or content catalog API. How would you structure it?

Design search and filtering for a backend catalog

Designs search and filtering with controlled query contracts, indexing, pagination, ranking, and operational limits.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would start with the search use cases: free text, filters, sorting, pagination, and which fields are searchable. The API would expose a controlled query contract with allowed filters and sort options, not arbitrary SQL-like input. For simple cases, SQL indexes may be enough. For richer text search, ranking, stemming, typo tolerance, or facets, I would consider a search index such as Elasticsearch.

Full answer below

Practice focus

Search contract design, query validation, indexes, pagination, relevance, caching, consistency, and performance limits.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Search design connects product behavior and backend constraints. The API needs to feel flexible without letting clients create unbounded database or search-engine load.
I would start with the search use cases: free text, filters, sorting, pagination, and which fields are searchable. The API would expose a controlled query contract with allowed filters and sort options, not arbitrary SQL-like input. For simple cases, SQL indexes may be enough. For richer text search, ranking, stemming, typo tolerance, or facets, I would consider a search index such as Elasticsearch.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate source-of-truth data from search projection. The database remains authoritative, while the search index stores fields optimized for search. Updates can flow through events, an outbox, or a background indexer. The API needs predictable pagination, usually cursor or search-after style for deep result sets, and clear limits on page size and filter combinations. I would also define how fresh search results need to be because eventual consistency may be acceptable for catalog search but not for security-sensitive data.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor query latency, no-result rate, expensive filter combinations, index lag, failed indexing events, relevance changes, and source-to-index reconciliation. Search-index outages need an explicit response: degraded SQL lookup for a narrow critical path, cached popular results, or a clear temporary limitation rather than an unbounded fallback. Relevance is an owned product loop with versioned analyzers and measurable outcomes, while query telemetry avoids retaining sensitive search terms unnecessarily. Reindexing, schema migration, alias cutover, and rollback are tested so the projection can evolve without making the source-of-truth data unavailable.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Letting clients send arbitrary filter or sort fields.
Using offset pagination for very deep result sets without limits.
Assuming the search index is always perfectly fresh.
Ignoring no-result and relevance feedback.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot choose between SQL search and a search index.
Has no indexing or reindexing story.
Ignores query abuse and expensive filters.
No fallback when the search engine is down.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is SQL enough for search?
How would you keep the index updated?
How would you paginate search results?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Opening drill

System designMedium~16 min

Interview question

Design search and filtering for a product or content catalog API. How would you structure it?

Design search and filtering for a backend catalog

Designs search and filtering with controlled query contracts, indexing, pagination, ranking, and operational limits.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Search contract design, query validation, indexes, pagination, relevance, caching, consistency, and performance limits.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Search design connects product behavior and backend constraints. The API needs to feel flexible without letting clients create unbounded database or search-engine load.
I would start with the search use cases: free text, filters, sorting, pagination, and which fields are searchable. The API would expose a controlled query contract with allowed filters and sort options, not arbitrary SQL-like input. For simple cases, SQL indexes may be enough. For richer text search, ranking, stemming, typo tolerance, or facets, I would consider a search index such as Elasticsearch.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate source-of-truth data from search projection. The database remains authoritative, while the search index stores fields optimized for search. Updates can flow through events, an outbox, or a background indexer. The API needs predictable pagination, usually cursor or search-after style for deep result sets, and clear limits on page size and filter combinations. I would also define how fresh search results need to be because eventual consistency may be acceptable for catalog search but not for security-sensitive data.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor query latency, no-result rate, expensive filter combinations, index lag, failed indexing events, relevance changes, and source-to-index reconciliation. Search-index outages need an explicit response: degraded SQL lookup for a narrow critical path, cached popular results, or a clear temporary limitation rather than an unbounded fallback. Relevance is an owned product loop with versioned analyzers and measurable outcomes, while query telemetry avoids retaining sensitive search terms unnecessarily. Reindexing, schema migration, alias cutover, and rollback are tested so the projection can evolve without making the source-of-truth data unavailable.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Letting clients send arbitrary filter or sort fields.
Using offset pagination for very deep result sets without limits.
Assuming the search index is always perfectly fresh.
Ignoring no-result and relevance feedback.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot choose between SQL search and a search index.
Has no indexing or reindexing story.
Ignores query abuse and expensive filters.
No fallback when the search engine is down.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is SQL enough for search?
How would you keep the index updated?
How would you paginate search results?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Design search and filtering for a product or content catalog API. How would you structure it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Design search and filtering for a product or content catalog API. How would you structure it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice