Design a Resume Search System

Clarified whether resumes are unstructured files needing parsing or structured profile data
Established scale (tens of millions of resumes), query volume, and freshness SLA (minutes, not real-time)
Distinguished functional requirements (search, filter, rank, view) from non-functional (latency, availability, storage)

Proposed an async ingestion pipeline (upload → blob storage → queue → parsing → indexing) rather than synchronous indexing
Chose an inverted-index search engine (Elasticsearch/OpenSearch) for full-text + faceted queries, with a separate metadata DB as source of truth
Diagrammed clear data flow from upload through parsing, indexing, and query serving
Identified caching layer for repeated/popular queries and facet counts

Defined upload, detail-fetch, and search endpoints with realistic request/response shapes including filters and facets
Designed ES document schema distinguishing analyzed text fields vs. keyword fields for filtering/aggregation
Designed metadata store schema separating raw text from structured extracted fields

Addressed relevance ranking (BM25 + boosting signals, mention of LTR as extension)
Addressed resume parsing approach (extraction + NLP/NER + skills taxonomy normalization) and its rule-based vs ML tradeoff
Addressed index scaling (sharding, replicas, zero-downtime reindex via aliases)
Addressed access control / ACL filtering pushed into the search query rather than post-filtering
Addressed freshness vs. throughput tradeoff in the indexing pipeline (batching strategy)

Explicitly discussed at least 3 trade-offs (e.g., async vs sync indexing, ES vs Postgres full-text, ACL filter placement)
Managed time across requirements/design/deep-dive/wrap-up phases without over-indexing on one area
Gave a concise, structured opening/closing summary of the design

Problem