Search indexes are derived views optimized for retrieval. Updates and deletes must propagate from the source of truth with observable lag.
Before you start
You should understand API requests, storage and basic capacity estimates. Begin with a concrete user action and its correctness requirement. Draw data flow and failure boundaries before selecting infrastructure; a technology name by itself does not explain why a design meets the requirement.
The practical goal is to reason through this situation: A catalog change reaches the search index asynchronously. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Keep source authority
The index is a derived retrieval view, not the owning business record.
Step 2: Track update progress
Lag and deletions need observable propagation.
Step 3: Rebuild with a boundary
Load a known snapshot, catch up changes and validate before switching.
Worked scenario
A catalog change reaches the search index asynchronously.
A new index is built while the catalog keeps changing. Copying records without a change-catchup strategy misses edits and deletions during construction. Establish a source boundary, apply subsequent changes and compare meaningful counts or sampled results before switching reads under a recovery plan.
Common mistake
Searching successfully does not mean the index is current or authoritative.
Verify the behavior
Update and delete records during rebuild, then verify the new index converges.
Interview exercise
Rebuild an index safely.
Answer and reasoning
Create a new index from a known source boundary, catch up changes and switch reads after validation.
Continue learning
Compare the scenario with the System Design interview questions and test your understanding with the System Design MCQs. For terminology and implementation details, consult the reference material.