Backend interview: How would you design controllable hybrid similarity search with Redis Vector Sets?

Question

You need Redis vector sets for product semantic search with tenant, year, and inventory filters. How would you design writes, VSIM queries, capacity, and quality validation?

Context and boundaries

Each element has a string ID, a fixed-dimension vector, and optional JSON attributes. Redis vector sets use HNSW for similarity search and support simple mathematical filters through FILTER. Cover updates, deletes, cold start, memory limits, cross-platform FP32 encoding, and search fallback; do not describe the feature as a black box that guarantees business-level exact recall.

What the interviewer is testing

The interviewer wants one service contract for vector retrieval, structured constraints, data lifecycle, and capacity. Redis documents VADD for adding or updating elements, VSIM for vector similarity queries, and attribute filters that decide which candidates remain; FP32 blobs require little-endian byte order, while VALUES avoids platform-specific blob encoding.

Clarify these points first:

• What are vector dimension, distance metric, tenant volume, and update frequency?
• Are filters hard constraints, or may the application re-filter an expanded candidate set?
• Do results need top-k, similarity scores, attributes, or an explainable filter reason?
• What are memory, persistence, recovery, and cross-zone replication requirements?

30-second answer

Define the key, element ID, vector dimension, and attribute schema. Explain idempotent VADD/VSETATTR writes, VSIM top-k and filtering. Finish with capacity estimates, a quality baseline, and keyword or previous-index fallback when Redis is unavailable.

Step-by-step deep dive

1. Data contract: fix dimension and model version; make IDs global or key them by tenant; store only filter fields as attributes.
2. Write path: validate dimension and model version, idempotently update the vector with VADD, update attributes with VSETATTR, and delete with VREM.
3. Query path: validate tenant boundaries and filter expressions in the service, request slightly more than final k from VSIM, and return scores and attributes for auditing.
4. Capacity: estimate vector, HNSW-link, and attribute memory; set per-tenant limits, eviction policy, and sharding; avoid arbitrary large JSON attributes.
5. Consistency and recovery: record model version and write events; after snapshot restore verify dimensions, element count, and sampled recall; failed updates must not leave half-new attributes.
6. Quality and fallback: measure Recall@k, filtered hit rate, and p95 latency on labeled data; switch to keyword retrieval or an older snapshot when Redis or filtering is unavailable.

Model answer

I would key the set by tenant and model version, keep element IDs stable, and fix the vector dimension. On write, I would validate dimension and model version, idempotently update the vector with VADD, then store year, inventory, and tenant attributes with VSETATTR; deletion uses VREM. The service validates tenant constraints before requesting slightly more than k candidates:

VSIM products:{tenant}:{model} VALUES 3 0.12 0.08 0.44 COUNT 50 WITHSCORES FILTER ".year >= 2024 && .stock > 0"

I would track dimensions, element count, HNSW information, and attribute memory, with per-tenant limits. The benchmark measures Recall@k, filtered hit rate, p95/p99 latency, read/write throughput, and recovery time, using exact brute-force search as a quality baseline. FP32 transport uses little-endian encoding, or VALUES to avoid blob endianness differences. If Redis, filtering, or model-version compatibility fails, I would fall back to keyword retrieval or the previous snapshot and record the result source.

Common mistakes

• Saying “HNSW is fast” without dimension, k, filter, or quality metrics.
• Treating attribute filters as arbitrary SQL and ignoring expression limits or tenant isolation.
• Writing model outputs of arbitrary dimensions into one vector set.
• Ignoring FP32 endianness, JSON attribute size, and HNSW memory cost.
• Having no old-index, keyword, or snapshot-recovery fallback.

A strong answer connects writes, queries, capacity, consistency, and quality validation; states Redis command boundaries; and gives measurable fallback behavior. A weak answer only says “add filters to a vector database” without a data contract or operating metrics.

Follow-up questions and responses

Why not store every business field as an attribute?

Attributes participate in filtering and consume memory. Keep only candidate-filter fields, then fetch details by ID from the primary store to avoid index bloat and privacy spread.

What if a model upgrade changes the dimension?

Create an independent key or version space for the new model, dual-write and evaluate it, then switch after Recall@k, latency, and cost gates pass. Never mix dimensions in one set.

What if a strict filter returns no results?

Return an explicit zero-result reason and metric. Relax conditions in the product-approved order or switch to keyword retrieval; never silently return results that violate tenant or inventory constraints.

Interview checklist

One-sentence takeaway

Treat a vector set as a retrieval component with explicit dimension, attribute, and capacity contracts, then use quality baselines and safe fallback for controllable search.