ORIGINAL COMPANY-CONTEXT PRACTICE
Keep a search index fresh through source deletions
Original practice scenario: Design a hypothetical search index for frequently changing public documents. Updates arrive late and an old document version may reappear after deletion. How do you prevent stale resurrection?
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Model indexed documents as versioned source records and make deletion a durable state transition. Search availability and source freshness require separate service objectives.
Work through it
- Assign a source identity and monotonic source version where available; store the version accepted by the index and reject older updates.
- Propagate tombstones through ingestion, indexing and caches, retaining them long enough to outlive expected replay and recovery windows.
- Support a replayable change log and reconciliation scan, exposing lag and missed-deletion metrics separately from query latency.
Tradeoffs to discuss
- Frequent refreshes improve freshness but increase indexing work; incremental updates are efficient while periodic rebuilds offer a useful consistency check.
Common pitfalls
- Arrival time does not prove source ordering when retries or batch exports delay events.
- Test delete-then-recreate semantics explicitly; a new source object may need a different generation identity.