Elasticsearch

Elasticsearch is a distributed search and analytics engine built on Lucene. Documents live in indices split into shards; each shard is a Lucene index with its own inverted index. Mappings define field types and analyzers; queries hit the inverted index and return scored hits plus aggregations.

| Concept | Role | |---------|------| | Index | Logical namespace of documents | | Shard | Unit of distribution and parallelism | | Mapping | Schema: types, analyzers, multi-fields | | Analyzer | Tokenization pipeline at index and query time | | Refresh | Makes recent writes visible for search (near-real-time) |

Typical architecture: application writes to PostgreSQL as source of truth, syncs denormalized search documents via CDC or batch jobs, queries Elasticsearch for user-facing search and filters.

					PUT /products/_doc/1
{ "title": "Wireless keyboard", "brand": "Acme", "price": 79 }
				

On interviews: explain why search is a separate store, how shards scale reads/writes, what mappings cost at reindex time, and operational concerns (heap, segment merges, yellow/red cluster state).

Common pitfalls: treating Elasticsearch as primary database; dynamic mapping surprises on new fields; huge documents; default 5 shards on small clusters; ignoring refresh interval for write-heavy workloads; aggregations on high-cardinality fields without filters.

The trade-off is rich search relevance and fast filtered retrieval versus operational complexity, eventual consistency with the source DB, and reindex/migration cost when mappings change.

Checklist:

• Name index, shard, replica, mapping, analyzer.
• Separate source of truth from search index.
• Describe sync path and staleness tolerance.
• Mention refresh, scoring, and aggregation limits.
• Note cluster health and reindex strategy.