A derived retrieval system, not a slow-query reflex#
Use a dedicated search engine when users need token-aware search, ranking, filters, facets, highlighting, or large-scale log retrieval. First ask whether a normal database index solves the query. Product search and transactional truth are different responsibilities.
Clusters divide indexes into primary and replica shards#
At interview depth, both Elasticsearch and OpenSearch organize documents into indexes divided into shards. Primary shard copies receive indexing operations; replicas provide redundant copies and can serve reads. A coordinating node fans a search to relevant shard copies and merges local results. The products share lineage and concepts, but exact features and defaults can diverge - verify the chosen product.
An acknowledged index write and a searchable document are distinct moments#
Refresh operations make recent indexed changes available to search. Elasticsearch and OpenSearch expose refresh controls and periodic behavior, but defaults and hosted variants can differ. Design from the required visibility delay and cost; do not hardcode a universal one-second guarantee.
Query fan-out creates both parallelism and overhead#
Query
→ relevant shard copies
→ local retrieval + ranking
→ coordinating merge
→ resultsToo many tiny shards can increase coordination, memory, recovery, and merge work. Too few oversized shards can constrain distribution and recovery. Avoid formulaic shard counts; state data volume, traffic, routing, growth, and failure requirements.
Search failure should not corrupt the source of truth#
- Failure
- Indexing falls behind or a mapping change requires reindexing.
- Impact
- Search returns stale, missing, or incorrectly ranked documents while authoritative records remain correct.
- Detection
- Measure pipeline lag, failed indexing operations, query errors, cluster health, and index-versus-source reconciliation samples.
- Mitigation
- Retain replayable change history, make indexing idempotent, support backfill/rebuild, version indexes, and switch aliases or routing after validation.
- Trade-off
- Derived indexes add retrieval power at the cost of synchronization and operating complexity.
Fit and alternatives#
| Good reason | Weak reason |
|---|---|
| Full-text analysis and relevance are product requirements. | One SQL query is slow and lacks an appropriate index. |
| Filtering/faceting or log retrieval justifies a derived index. | You need correctness-critical multi-row transactions. |
| You can tolerate and repair an explicit freshness window. | You have no replay or reindex strategy. |
- Using search as the only authoritative transactional store without justification.
- Ignoring indexing lag, deletes, duplicates, and rebuilds.
- Assuming Elasticsearch and OpenSearch remain behaviorally identical.
- Prescribing a shard count without workload evidence.
- Adding search infrastructure before fixing a database index.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Where is the source of truth?
- How stale may search results be?
- How are deletes, duplicates, and replay handled?
- What happens during a full reindex?
- Can routing avoid querying every shard?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Shard allocation, relocation, and recoveryElastic Documentation
- Elasticsearch refresh parameterElastic Documentation
- OpenSearch Refresh Index APIOpenSearch Documentation