Elasticsearch Interview Questions India 2026: Search Architecture, Query DSL, and Performance

Elasticsearch fundamentals:

1. What is Elasticsearch? Elasticsearch is a distributed search and analytics engine built on Apache Lucene. It stores documents as JSON and indexes them for fast full-text search and analytics. It is the 'E' in the ELK stack (Elasticsearch, Logstash, Kibana).

2. The inverted index: The inverted index is the core data structure that makes Elasticsearch fast. For each unique term in a document, the inverted index stores the list of document IDs that contain that term. Search works by looking up query terms in the inverted index, not by scanning every document.

Example: Three documents about companies:

• Doc 1: 'Swiggy food delivery'
• Doc 2: 'Zomato food delivery'
• Doc 3: 'Swiggy IPO'

Inverted index: 'swiggy' -> [1, 3], 'food' -> [1, 2], 'delivery' -> [1, 2], 'zomato' -> [2], 'ipo' -> [3]

Querying for 'swiggy food': look up 'swiggy' and 'food' in the inverted index, intersect [1, 3] and [1, 2], return doc 1 (contains both terms).

3. Shards and replicas: - Index: a collection of documents (analogous to a database table). Documents are stored as JSON. - Shard: an index is divided into N primary shards. Each shard is a complete Lucene index. Shards distribute data across nodes for horizontal scaling. - Replica: a copy of a primary shard. Replicas provide fault tolerance (if a node fails, replicas on other nodes continue serving) and increased read throughput (reads can be served by both primary and replica shards). - Setting shards: the number of primary shards must be set at index creation time and cannot be changed (without reindexing). Over-sharding (too many shards for the data volume) causes overhead; under-sharding (too few shards) limits scaling.

4. Analysis and tokenisation: Before indexing, text goes through an analyser: character filters (remove HTML), tokeniser (split text into tokens; standard tokeniser splits on whitespace and punctuation), token filters (lowercase, remove stop words, stem). Different analysers for different languages and use cases. The same analyser applied at index time must be applied at query time for consistent results.

Querying Elasticsearch:

1. Query types: - match: full-text search (text goes through the analyser). The most common query type for user-facing search. - term: exact match on the raw value (no analysis). Use for IDs, status fields, keyword fields, and boolean values. - bool: combine multiple queries. must (AND), should (OR; must match at least one), mustnot (NOT), filter (AND but does not affect relevance score). - range: find documents where a field value is within a range (date range, price range). - fuzzy: tolerates typos (edit distance of 1 or 2). - multimatch: search the same text across multiple fields. - nested: query nested objects (arrays of objects in Elasticsearch have a special mapping type).

2. filter vs query context: Query context: queries that calculate a relevance score (_score). More expensive (score calculation). Use when you want ranked results. Filter context: queries that simply check if a document matches (binary yes/no; no score). Faster and cacheable. Use for filtering (date range, category, status) in combination with a full-text match query.

3. Aggregations: Aggregations are Elasticsearch's analytics engine. Terms aggregation: count documents by field value (like GROUP BY in SQL). Date histogram: count documents per time bucket (events per day). Range: bucket documents by value ranges. Nested aggregations: aggregate within aggregations (e.g., for each restaurant in the search results, compute the average rating).

4. source, score, and explain: source: the original JSON document stored and returned in results. score: the relevance score for the query (higher = more relevant). explain=true: shows how the score was calculated (useful for debugging unexpected ranking).

Elasticsearch mappings and operations:

1. Mappings: A mapping defines the schema of an index (field names, types, analyser). Field types: text (full-text search; analysed), keyword (exact match; not analysed; sorting and aggregations), integer, long, float, boolean, date, geo_point, nested. Dynamic mapping: Elasticsearch auto-detects field types. Explicit mapping: define the mapping upfront to control types and analysers.

2. Dynamic vs keyword vs text: A common mistake: mapping a field that needs both full-text search and exact filtering as text. Solution: use multi-fields to index the same field in multiple ways: ```json { "properties": { "name": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } } } } ``` Use name for full-text search; use name.keyword for sorting and exact aggregations.

3. Index lifecycle management (ILM): ILM automatically manages index lifecycle: hot phase (active indexing and search), warm phase (less frequent access; optimise for storage), cold phase (rarely accessed; frozen), delete phase (auto-delete old indices). Essential for time-series indices (logs, events) where old data should be archived or deleted.

4. Reindexing: The _reindex API copies documents from one index to another. Use for: changing the number of shards, changing mappings (field types cannot be changed in place), upgrading Elasticsearch versions. Zero-downtime reindexing: use an alias that points to the current index; reindex into a new index; switch the alias to the new index; the alias swap is atomic.

Elasticsearch performance:

1. Indexing performance: bulk API: always use the bulk API for indexing multiple documents (not individual index calls). index.refreshinterval: Elasticsearch makes new documents searchable by refreshing segments every second. During heavy indexing, set refreshinterval to -1 (manual refresh only) and restore after indexing. replica count during indexing: set replicas to 0 during bulk indexing; restore after.

2. Search performance: Use filter context for non-scoring queries (range, term) — filters are cached. Avoid script queries (slow; no caching). Use pagination with searchafter (not from/size for deep pagination: from + size = 10,000 is the default limit). Use source to return only needed fields.

3. Common performance pitfalls: - Mapping explosion: too many dynamic field mappings (e.g., storing arbitrary JSON keys as fields). Fix: use explicit mappings; disable dynamic mapping for objects that should not be searched. - Too many shards: small indices with too many shards waste resources. Rule of thumb: shards should be 10-50 GB each. - High JVM heap pressure: Elasticsearch runs on the JVM; allocate 50% of available RAM to JVM heap (but never more than 30-31 GB to avoid pointer compression issues).

4. Monitoring Elasticsearch: Key metrics: JVM heap usage (alert above 75%), disk usage per node, indexing rate (documents/second), search rate, search latency (p95, p99). Tools: Kibana's Stack Monitoring, Elastic APM, Prometheus + Elasticsearch Exporter + Grafana.