How the interviewer opens it
“Design a database that stores embeddings and returns similar items through approximate nearest-neighbor search. Clients must also filter the results by metadata.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Operations and distance
- Data size and tenants
- Traffic and read:write mix
- Metadata filters
- Search quality
- Query time
- Freshness and availability
- Durability
- Index changes
- Exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Store, replace, read, and delete vectors by tenant and record ID
- Return the nearest vectors that satisfy metadata filters
- Meet the stated recall, query time, and freshness targets
- Keep each tenant's data separate from other tenants
Usually out of scope
- Create embeddings or train models
- Combine vector search with text search
- Support arbitrary SQL queries or joins
- Operate across multiple regions
What interviewers ask about
- Search results with filters
- The nearest vectors may fail the filter. A selective filter can also make graph search miss valid neighbors.
- Search quality and query time
- Search effort improves recall but consumes query time and CPU. Filters and tenant size change that trade-off.
- Changes to stored vectors
- Writes must survive failures before search sees them. Updates and deletes must remain correct during index replacement.
- Queries across tenants and shards
- A large tenant can span shards. Every shard affects global recall and query time, while small tenants need little search work.
Common mistakes
- Measure recall against unfiltered neighbors instead of the exact filtered result set.
- Treat a filter as a final step after a fixed-size ANN result.
- Treat an ANN index as the only durable copy of the records.
- Ignore obsolete vectors and delete markers during index replacement.
- Size memory from vector bytes alone and ignore replicas, graphs, and metadata indexes.
- Search every shard without a tenant route or a plan for slow shards.
The bar by level
- Senior (L5/E5)
- Designs filtered search with exact-scan fallback. Sizes memory and replicas. Defines recall tests, write visibility, version checks, recovery, and complete results across shards.
- Staff (L6+/E6+)
- Defines quality and freshness contracts under overload and failure. Designs safe index replacement and tenant moves. Uses measurements to choose memory, recall, and query-time trade-offs.