Architecture and Cluster Fundamentals
A recurring interview question is to explain the relationship between a cluster, nodes, indices, shards, and replicas: a cluster is a set of nodes sharing a cluster name and state, each index is split into a fixed number of primary shards decided at creation time, and each primary can have zero or more replica shards for redundancy and read scaling. Interviewers often follow up by asking why primary shard count can't be changed after index creation without reindexing — the answer is that document routing to a shard is computed as a hash of the document's routing value modulo the number of primary shards, so changing that number would invalidate the mapping between existing documents and their shards. A good answer also covers how the elected master node manages cluster state (mappings, index settings, shard allocation) without necessarily handling data traffic itself, especially in larger clusters that use dedicated master-eligible nodes.
Cricket analogy: This is like explaining how a T20 league's franchise system works: the league (cluster) has multiple franchises (nodes), each franchise fields a squad (index) split into fixed batting and bowling units (shards) decided at squad registration, with backup players (replicas) ready in case of injury.
Indexing, Mappings, and Analysis
A common question is to explain the difference between a text field and a keyword field: text fields are analyzed at index time, running through a tokenizer and filters (like the standard analyzer's lowercasing and tokenization) to support relevance-scored full-text search, while keyword fields are stored as-is for exact matching, sorting, and aggregations. Candidates should also be ready to explain mapping explosion, where dynamic mapping on unpredictable or user-supplied field names can create thousands of unique fields and destabilize cluster performance, and how to mitigate it with a dynamic: false or dynamic: strict setting combined with explicit mappings for known fields. Another frequent topic is the difference between refresh (making recently indexed documents searchable, by default every 1 second) and flush (persisting the in-memory Lucene segment and translog to disk), since confusing the two is a common source of incorrect claims about durability versus search visibility.
Cricket analogy: This is like explaining the difference between a ball tracked with full trajectory data for analysis (text field, analyzed) versus a simple pass/fail wicket outcome logged for the scoreboard (keyword field, exact match) — same event, different representations for different needs.
Query Behavior and Relevance
Interviewers frequently ask candidates to explain the difference between a query context and a filter context: queries calculate a relevance _score answering "how well does this document match", while filters answer a yes/no "does this document match" and are cacheable, which is why bool queries commonly place scoring conditions in must/should and non-scoring conditions like date ranges or status checks in filter for both performance and clarity. Another classic question covers BM25, the default scoring algorithm since Elasticsearch 5, and why it improves on older TF-IDF: BM25 saturates term frequency (repeating a term many more times gives diminishing score returns) and normalizes for document length so that a match in a short field isn't unfairly penalized compared to a long one. Strong candidates can also discuss how a match_phrase query respects term order and slop, and why aggregations on text fields require a fielddata-enabled sub-field or, more commonly, a parallel keyword sub-field defined in the mapping.
Cricket analogy: This is like the difference between a batter's exact runs-scored tally (filter context, a definite fact) and a pundit's subjective 'player of the match' rating (query context, a scored judgment) — one is binary truth, the other is weighted opinion.
GET products/_search
{
"query": {
"bool": {
"must": [
{ "match": { "description": "wireless noise cancelling headphones" } }
],
"filter": [
{ "term": { "in_stock": true } },
{ "range": { "price": { "lte": 300 } } }
]
}
}
}A strong interview signal is when a candidate explains that filter clauses are cached and don't affect scoring, so moving non-relevance conditions like status or date ranges out of 'must' and into 'filter' both speeds up repeated queries and clarifies query intent.
A common wrong answer is claiming that refresh_interval controls data durability. It only controls search visibility of recently indexed documents; durability is governed by the translog and flush behavior, which persist data to disk independently of refresh.
- Be ready to explain cluster/node/index/shard/replica relationships and why primary shard count is fixed at creation.
- Know the difference between text (analyzed) and keyword (exact match) fields and when to use each.
- Understand mapping explosion risk from unrestricted dynamic mapping and how dynamic: strict mitigates it.
- Distinguish refresh (search visibility) from flush (durability to disk) precisely.
- Explain query context (scored) versus filter context (cacheable yes/no) and why it matters for performance.
- Be able to describe BM25's term frequency saturation and document length normalization versus TF-IDF.
- Know why aggregating on analyzed text fields typically requires a keyword sub-field in the mapping.
Practice what you learned
1. Why can't the number of primary shards be changed after an index is created without reindexing?
2. What is the key difference between a text field and a keyword field?
3. What does the refresh operation control in Elasticsearch?
4. Why does BM25 improve on classic TF-IDF scoring?
Was this page helpful?
You May Also Like
Elasticsearch Quick Reference
A condensed cheat sheet of core Elasticsearch REST API endpoints, Query DSL patterns, and cluster commands for daily use.
Elasticsearch vs Other Search Engines
How Elasticsearch compares to Apache Solr, OpenSearch, Algolia, and database-native search like PostgreSQL full-text search.
Elasticsearch Security Basics
Core security features of Elasticsearch: authentication, role-based access control, TLS, and audit logging.