Back to System Design
System Design
Job matching system
Senior level · full staged walkthrough
Senior
Architecture
SeniorClientServiceDataEdge
Solution, step by step
- 1
Functional requirements
- Match candidates to relevant jobs
- Rank by fit (skills, location, salary)
- Explain why a match surfaced
- 2
Non-functional requirements
- Recommendation latency < 300ms
- Refresh embeddings as profiles change
- Scale to millions of postings
- Online + offline scoring
- 3
Capacity & estimation
- 10M postings, 50M candidates → vector index of tens of millions
- Embeddings ~768 dims × 4 bytes ≈ 3 KB each → ~150 GB
- ANN query budget: tens of K QPS
- Re-rank top ~500 candidates per query
- 4
Preliminary design
- Embed resumes & JDs into vectors
- ANN retrieval of candidates
- Re-rank with a feature model
- 5
Final architecture
- Embedding service generates vectors for resumes and JDs
- ANN index (HNSW/IVF) for fast candidate retrieval
- Ranking model re-scores with structured features from a feature store
- Feed API merges recall + ranking + business rules
- Feedback loop (clicks/applies) retrains ranking offline
Interview Q&A (8)
Embed resumes and job descriptions into vectors, retrieve top-N candidates with approximate nearest-neighbor (ANN) search, then re-rank with a feature model.
Key components
- Embedding service
- Vector index
- Ranking model
- Feature store
- Feed API
Bottlenecks & how to address them
- ANN index memory → quantization/sharding
- Embedding refresh lag → incremental updates
- Re-rank cost → cap candidate set
Tradeoffs to articulate
- Recall (ANN) vs precision (re-rank)
- Freshness of embeddings vs cost
- Explainability vs raw accuracy
Where this content comes from
For full transparency, this content is curated and verified from these sources:
Published architecture case studiesCompany engineering blogsOppZen design rubric library