Ancestry·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

May 2026

Summary

System design round at Ancestry focused entirely on building a data store around user feedback text. Pretty open-ended and went deep fast, covering everything from raw ingestion to embedding pipelines to query scaling.

Questions Asked (1)

Design a database or data store that is powered by user feedback text. Walk through how you'd handle ingestion of free-form feedback, schema design, a parsing and embedding pipeline, query patterns like search and aggregation, and how you'd scale the whole thing.

System DesignData ModelingTechnical Trade-offs

Author's notes

This felt like four questions stitched into one.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a hybrid architecture that separates raw text storage from derived structured data and vector embeddings. Walk through each pipeline stage (ingestion, parsing, embedding, indexing) and justify technology choices with trade-offs, emphasizing scalability and query performance.

Pro tip: Anchor your design around the query patterns first—search, aggregation, and analytics—because they dictate the schema and indexing strategy. Also, mention how you'd handle evolving feedback (e.g., new entities) without costly re-processing.

1. Clarify Requirements and Scale

Ask about data volume, velocity, query types, latency requirements, and consistency needs. Establish whether the system is read-heavy or write-heavy and what the expected growth is.

2. Design Ingestion and Raw Storage

Propose a scalable ingestion pipeline (e.g., Kafka) to buffer and process feedback. Store raw text in a durable, cheap store like S3 or a document database (e.g., MongoDB) for replayability and auditing.

3. Build Parsing and Enrichment Pipeline

Outline steps to clean, tokenize, and extract structured data (e.g., entities, sentiment) using NLP. Use a stream processor (e.g., Spark Streaming) to transform and write to downstream stores.

4. Generate and Index Embeddings

Use a model (e.g., sentence-transformers) to create vector embeddings. Store them in a vector database (e.g., Pinecone, Milvus) for semantic search, and also index text in a search engine (e.g., Elasticsearch) for keyword search.

5. Support Query Patterns and Scale

Design for search (hybrid keyword+semantic), aggregation (e.g., sentiment trends), and analytics. Scale horizontally by partitioning data, using read replicas, caching, and async processing.

Key Points to Mention

Use a lambda architecture or kappa architecture to handle both batch and stream processing for feedback.
Store raw feedback immutably for reprocessing and model retraining.
Leverage a vector database for semantic search and a traditional search engine for keyword search, combining results via re-ranking.
Design schema with a flexible document model for raw text and a normalized relational model for extracted entities to support aggregations.
Consider cost and performance trade-offs: embeddings are expensive to compute, so cache and batch process where possible.
Ensure scalability by sharding based on user or time, and use CDN/caching for frequent queries.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.