How would you update the vector index without causing downtime?
- 1 min — incremental vs structural changes.
- 3 min — blue-green: dual-write, shadow read, alias flip, rollback.
- 1 min — deletion churn and compaction.
- 1 min — capacity and cutover criteria.
Two cases. Incremental updates (new and changed documents): upsert in place — modern vector stores handle this online. Watch index quality drift in graph-based indexes after heavy deletion churn, and schedule compaction. Structural changes (new model, new chunking, new index type): blue-green. Build a parallel index, dual-write live changes to both, shadow-read to compare, then flip an alias behind a flag with the old index retained for rollback.
Route reads through an alias, never a hard-coded index name. The cutover is then an alias update — atomic, instant, and instantly reversible. That one indirection converts a risky migration into a boring one.
Mention deletion semantics specifically: most ANN indexes soft-delete, so deleted vectors still occupy memory and still get traversed until compaction. A high-churn corpus degrades in both latency and recall if nobody compacts. That detail signals you've operated one of these, not just deployed one.
Org scope: blue-green needs 2× index capacity for the migration window — budget it with finance before a model upgrade, not during. The platform owns the alias and cutover runbook; product teams sign off on the shadow-read comparison for their own golden sets.
What the answer sounds like at each level
Build a new index alongside the old one and switch over when it's ready.
Upserts for incremental changes; blue-green with dual-write, shadow reads and an alias flip for structural changes, keeping the old index for rollback.
Plans 2× capacity and cutover criteria up front, schedules compaction against soft-delete churn, and makes the alias the only way any service reads an index.
Follow-ups the interviewer will push
1How do you decide the new index is safe to flip to?
Shadow-read 1–5% of live queries to both, compare top-10 overlap and golden-set nDCG per tenant; flip only if no tenant regresses beyond a threshold (e.g. 2 points nDCG). Then ramp via canary 5% → 25% → 100% with automatic rollback on quality or latency alerts.
2Deletes are 30% of the corpus per month. What do you watch?
Tombstone ratio per segment, p95 latency and measured ANN recall. Compact (or rebuild the segment) when tombstones exceed ~20%, off-peak, and verify recall after.
Red flags interviewers listen for
- Rebuilds the index in place and accepts downtime.
- Hard-codes index names in services.
- Unaware that deletes are soft and need compaction.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Migration design | Blue-green with alias indirection and retained rollback. |
| Validation | Shadow reads and per-tenant comparison before cutover. |
| Operational depth | Soft deletes, compaction and capacity planning. |
Sources
- Elasticsearch reference: Aliases — Elastic, 2024docs
- Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs — Malkov & Yashunin, 2016paper