Interactive guide · 4 chapters · ~14 min read
Elasticsearch Interview & Revision
The questions interviewers actually ask, condensed revision notes, a self-check quiz, and a one-page cheat sheet for the night before an interview.
Mangesh MandlikLast updated:
01 · Interview Questions
Interview Questions
These are the questions that come up again and again in system design and backend engineering interviews when Elasticsearch is on the table.
"What is an inverted index and why does it make search fast?"
It maps each term to the documents containing it, turning a linear scan into a direct lookup — explain the term → postings-list structure.
"What's the difference between text and keyword fields?"
text is analyzed into terms for full-text matching; keyword is stored exactly and matched precisely. Give the term-on-text mistake as a concrete example.
"How does Elasticsearch rank search results?"
BM25 scoring, combining term frequency, inverse document frequency, and field-length normalization.
"How does Elasticsearch scale?"
Indices are split into primary shards spread across nodes; replicas add availability and read throughput; a search fans out to every shard (query phase) and merges results (fetch phase).
"What happens when a node holding a primary shard fails?"
The elected master promotes a replica of that shard to primary on a different node — search/index continues, cluster health goes yellow then green once a new replica is allocated.
"Why is Elasticsearch called 'near' real-time?"
Writes are durable immediately (translog), but not searchable until the next refresh (default ~1s) turns the in-memory buffer into a searchable Lucene segment.
"Why wouldn't you use Elasticsearch as your primary database?"
No multi-document ACID transactions, near-real-time rather than immediate consistency, and mapping changes typically require reindexing.
"How would you design search for an e-commerce product catalog?"
Denormalized product documents (embedding category/brand names), text+keyword multi-fields for name/description, filters for price/category in filter context, aggregations for facets, and CDC from the primary database to keep the index in sync.
02 · Revision Notes
Revision Notes
The condensed version of everything else in this module — read this the night before an interview.
Architecture
Distributed, built on Lucene. Index → shards (primary + replica) → nodes. Any node can coordinate any request.
Indexing path
Document → analyzer (char filters → tokenizer → token filters) → terms → inverted index on the owning primary shard → replicated to replica shard(s).
Search path
Query phase (fan out to every shard, each scores locally) → merge + rank centrally → fetch phase (retrieve full documents for the final top-N only).
Scoring
BM25 = f(term frequency, inverse document frequency, field-length normalization).
Field types
text = analyzed, full-text, forgiving. keyword = exact, unanalyzed, used for filters/sorting/aggregations.
Availability
Replica promoted to primary automatically on node failure. Cluster health: green (all shards allocated) → yellow (primaries ok, replicas missing) → red (a primary is unallocated).
Consistency model
Near real-time — searchable after the next refresh (~1s default), not immediately after write.
03 · Quiz
Quiz
Test yourself — try to answer before reading further.
Q1. Why does a term query on a text field often return zero results even for an obviously present word?
Because term bypasses analysis and looks for an exact match against the raw indexed value, while a text field stores analyzed (lowercased, stemmed, tokenized) terms — the raw string rarely equals any single stored term.
Q2. If refresh_interval is 30 seconds, how soon after a successful index request can a document be found by search?
Not immediately — up to the next refresh cycle, so potentially close to 30 seconds later, even though the write itself was already durable.
Q3. What happens to search and indexing when a node holding a primary shard (with a healthy replica elsewhere) goes down?
The replica is promoted to primary on another node; search and indexing for that shard continue with no downtime, and cluster health temporarily shows yellow.
Q4. Why can't you simply increase the number of primary shards on an existing index?
Primary shard count determines how documents are routed/hashed to shards at index time — changing it would require redistributing every document, which is why it can't be changed in place — you reindex, or use the split/shrink APIs for compatible shard counts.
Q5. What are the three ingredients of BM25 relevance scoring?
Term frequency (how often the term appears in this document), inverse document frequency (how rare the term is across the index), and field-length normalization.
04 · Cheat Sheet
Cheat Sheet
A one-page reference for the concepts that come up most often.
textElasticsearch at a glance
Document → a JSON record, lives in one index + one primary shard
Index → collection of documents sharing a mapping (≈ a table)
Shard → a self-contained Lucene index; index = N primary shards
Replica → full copy of a shard, on a different node, for HA + reads
Mapping → field types + analysis config, expensive to change later
text → analyzed, full-text, forgiving (match query)
keyword → exact, unanalyzed, strict (term query)
Indexing path → doc → analyze → terms → inverted index → replicate
Search path → query phase (fan-out+score) → merge → fetch phase
Scoring (BM25)→ term frequency + inverse doc frequency + length norm
refresh → in-memory buffer → searchable segment (~1s default)
Cluster health→ green (all ok) · yellow (replicas missing) · red (primary missing)Key takeaways
- 01text = analyzed/forgiving, keyword = exact/strict — never mix up which query type goes with which.
- 02Search always runs in two phases: query (fan-out + local scoring) then fetch (retrieve full docs for the final top-N).
- 03Primary shard count is fixed at index creation; replica count can change anytime.
- 04"Near" real-time means durable immediately, searchable after the next refresh.
- 05BM25 = term frequency × inverse document frequency, normalized by field length.