Back to System Design
System Design
Resume parsing system
Mid level · full staged walkthrough
Mid
Architecture
MidClientServiceAsyncData
Solution, step by step
- 1
Functional requirements
- Extract structured fields from resumes
- Handle many formats (PDF/DOCX/scans)
- Flag low-confidence fields for review
- 2
Non-functional requirements
- High extraction accuracy
- Throughput over latency (batch ok)
- Privacy: PII handled securely
- Pluggable parsers
- 3
Capacity & estimation
- 1M resumes/day → ~12/s avg, batchy peaks
- OCR for scanned docs is CPU-heavy → worker pool
- Avg resume ~200 KB → ~200 GB/day ingest
- Low-confidence rate ~10% → review queue volume
- 4
Preliminary design
- Convert to text (OCR for scans)
- Section + entity extraction (NLP/LLM)
- Validate against a schema; queue low-confidence
- 5
Final architecture
- Ingestion service normalizes formats; OCR worker pool for scans
- Parser/LLM extracts sections + entities into a schema
- Confidence scoring routes uncertain fields to a human review queue
- Validated records stored + indexed; PII encrypted at rest
- Async, queue-driven pipeline for elastic throughput
Interview Q&A (8)
Normalize everything to text first — direct extraction for PDF/DOCX and an OCR worker pool for scanned images — before parsing.
Key components
- Ingestion service
- OCR
- Parser/LLM
- Schema validator
- Review queue
Bottlenecks & how to address them
- OCR CPU cost → autoscale workers
- LLM latency/cost → batch + cache
- Format edge cases → fallback parsers
Tradeoffs to articulate
- Rules (precise, brittle) vs ML (robust, fuzzy)
- Latency vs accuracy
- Human-in-the-loop cost
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