Articles

Elasticsearch Interview Questions: Inverted Indexes, Shards, Mappings, and Query Performance

Prepare for Elasticsearch interview questions on inverted indexes, mappings, shards, replicas, relevance, aggregations, and query performance.

Elasticsearch interview questions test whether you can connect text analysis, index topology, and query evidence to a production workload. A strong backend engineer explains which terms are indexed, which shards execute the request, how mappings shape access, and what measurements prove the bottleneck. Memorizing Query DSL is not enough; interviewers want a safe decision and its trade-offs.

What Elasticsearch interviewers are actually testing

Use one repeatable loop: Terms → Topology → Trace → Trade-off.

Terms: Trace source text through the analyzer into indexed terms and field-oriented values.
Topology: State the index, routing rule, primary shards, replicas, and expected shard fan-out.
Trace: Follow the request from coordinating node to shard query, fetch, aggregation, and merge; compare estimates and timings with cluster evidence.
Trade-off: Protect relevance, freshness, availability, write throughput, recovery time, and cost—not latency alone.

Area	Weak answer	Strong Elasticsearch signal
Inverted index	“It makes search fast”	Traces analyzer output to postings, positions, frequencies, and scoring implications
Mappings	“Use dynamic mapping”	Defines field contracts, exact versus full-text access, and growth limits
Shards	“Add more shards”	Connects routing and fan-out to data size, hot spots, recovery, and replicas
Performance	“Use the Profile API”	Separates client, coordinator, queue, shard, fetch, and resource evidence

How does an inverted index work in Elasticsearch?

An inverted index maps each indexed term to the documents that contain it. For a text field, Elasticsearch first analyzes the input: character filters can rewrite the character stream, one tokenizer creates tokens and records positions and offsets, and token filters can lowercase, remove, or add tokens. The resulting terms—not the original sentence—drive lexical matching.

Suppose the index analyzer turns “Fast, reliable search” into fast, reliable, and search. A match query analyzes the search text too, then uses those terms to find posting lists and score candidates. Positions support phrase and proximity behavior; term frequency and document statistics feed relevance. The exact stored structures depend on field settings, so avoid claiming every index stores every statistic.

A good answer also names the failure mode: incompatible index-time and search-time analysis can make documents undiscoverable. Use the Analyze API against the actual field, inspect tokens and positions, and test representative language, punctuation, identifiers, and synonyms. A normalizer differs from an analyzer because it emits one token for keyword-style values rather than tokenizing prose.

How should you design Elasticsearch mappings?

Treat a mapping as an index-time access contract. Decide how each field is searched, filtered, sorted, aggregated, and evolved. Dynamic mapping helps controlled inputs, but unbounded customer-defined keys can create mapping explosion, enlarge cluster state, consume heap, and reject documents at a configured limit.

Requirement	Typical mapping choice	Interview caveat
Full-text search	`text` with a deliberate analyzer	Analyzer changes usually require a new index and reindexing
Exact filter, sort, or terms aggregation	`keyword`, numeric, date, Boolean, or other structured type	Check value length, cardinality, and doc-values cost
Both prose search and exact grouping	`text` with a `keyword` multi-field	Each multi-field adds another mapper and index cost
Array of objects whose fields must stay paired	`nested` when independent object matching is required	Nested documents increase index and query work
Sparse, unpredictable keys	Controlled `flattened` or an explicit allowlist	Avoid one mapped field per arbitrary key

Incompatible type or analyzer changes normally require a new index. Create the target mapping, reindex, validate counts and queries, then switch an alias with a rollback plan. “Update the mapping in place” is not safe for changing an existing field from text to keyword.

Why do `text`, `keyword`, and doc values matter for performance?

text fields are analyzed for full-text retrieval. keyword fields preserve exact values for term-level queries, filtering, sorting, and aggregations. Most supported structured fields also receive doc values, an on-disk columnar representation optimized for document-to-value access. That access pattern differs from the inverted index’s term-to-document lookup.

This explains a common interview trap: aggregating on analyzed text is usually the wrong model. Map a suitable keyword multi-field or another structured type instead. Enabling fielddata on a large text field can load substantial data into heap; treat it as an exceptional decision backed by measurement, not a convenient query fix.

How do primary shards and replicas work?

Every document belongs to exactly one primary shard. A replica is another copy of a primary shard: it can serve reads, protects against a lost shard copy, and can be promoted if the primary fails. Indexing enters through the current primary copy and is then forwarded to replicas, so replicas improve redundancy and potential read capacity but also add write and storage work.

The number of primary shards is fixed when an index is created; the replica count is dynamic. Changing primary topology requires another index through split, shrink, or reindex workflows. Choose shard count from measured data volume, growth, node count, fan-out, recovery objectives, and hot-key distribution. Every shard adds metadata, memory, scheduling, and recovery overhead.

Custom routing can send a tenant’s documents to one shard or a subset, reducing fan-out for correctly routed searches. It can also make a large tenant a hot shard, and omitting the routing value later can cause misses or duplicate identifiers across shards. State the routing invariant and its enforcement at every read and write boundary.

What does refresh mean, and is Elasticsearch real-time?

Elasticsearch is near real-time for search visibility. A successful index response and a searchable document are distinct events. A refresh publishes recent segment changes so search can see them. Elastic Stack commonly refreshes active indices every second by default; Elastic Cloud Serverless uses a five-second default. Deployment settings can change both.

Do not confuse refresh with flush, durability, or replication. For a workflow that must index and then search the same document, refresh=wait_for waits for a refresh without normally forcing one. Repeated refresh=true can create tiny segments that cost at index, search, and merge time. In an interview, define the actual freshness service level instead of promising “instant search.”

How should you build a fast and relevant query?

Put clauses that affect relevance in query context and binary structured constraints in filter context. A bool query might use must or should for analyzed text, then filter for tenant, status, date, or permission boundaries. Filters avoid scoring work and frequently reused filters may be cached.

Start with the smallest correct query:

{
  "query": {
    "bool": {
      "must": [{ "match": { "title": "distributed search" } }],
      "filter": [
        { "term": { "tenant_id": "acme" } },
        { "term": { "status": "published" } }
      ]
    }
  },
  "size": 20
}

Then test analysis, boosts, phrase behavior, pagination, and correctness on a judged query set. Avoid deep from pagination, broad wildcards, unbounded scripts, and unjustified aggregation fan-out. Lower latency with worse relevance or broken access control is a regression.

How does BM25 relevance work, and how would you tune it?

BM25 is Elasticsearch’s default text similarity. It rewards term matches while applying term-frequency saturation, inverse document-frequency effects, and field-length normalization. The exact score also depends on the analyzer, query structure, field boundaries, boosts, and the shard-level corpus statistics used by the search.

Tune relevance in that order: verify tokens; confirm fields and clauses; build a labeled query set; measure ranking metrics such as NDCG; then consider boosts or similarity parameters. Use the Explain API for one document’s score and the Profile API for execution cost. Neither replaces relevance judgments.

How do aggregations affect Elasticsearch query performance?

Aggregations perform metric calculations, place documents into buckets, or consume earlier aggregation results. They can be expensive because every matching shard builds partial results and the coordinating node merges them. High-cardinality terms, large bucket sizes, scripts, wide time ranges, and many shards multiply work.

Map aggregation fields to structured types with doc values, filter time and tenant scope early, and request only needed buckets. Watch memory and circuit breakers. Precompute repeated summaries only when the freshness and accuracy contract allows it.

How do you debug a slow Elasticsearch query?

Start at the user-visible boundary and narrow the delay before editing mappings or adding hardware.

Capture the exact request, parameters, index or alias, routing, result count, payload size, and latency distribution.
Split client/network time from Elasticsearch’s end-to-end duration, coordinating-node queues, shard query work, fetch work, and aggregation reduction.
Check the target shard count, shard sizes, allocation, hot spots, thread-pool queues and rejections, CPU, heap pressure, garbage collection, disk latency, cache churn, and merges.
Use query logging or slow logs for historical candidates. Correlate hot threads with task management and node or index stats during the incident.
Reproduce safely with representative data. Profile one request, remembering that profiling adds overhead and omits network, queue, and coordinating-node merge time.
Change one variable, verify the same results and relevance, then remeasure p50, p95, p99, throughput, CPU, heap, and indexing impact.

That sequence prevents a local optimization from hiding a hot shard, broken mapping, broad request, queue backlog, or storage constraint.

Production scenario: one tenant creates a hot shard

Suppose p99 search latency rises while cluster-average CPU looks acceptable. One large tenant uses custom routing, so most of its data and traffic land on a single shard and node.

Prove skew with shard allocation, search queues, hot threads, task data, and tenant-tagged traces. A new replica may add read choices, but it does not split that shard’s data or remove primary indexing pressure. Durable fixes may use routing partitions, better tenant/index boundaries, a new primary-shard topology, or rollups—each with migration and correctness tests.

A seven-day Elasticsearch interview plan

Day	Focus	Evidence to produce
1	Analyze API and inverted-index reasoning	Explain five sample strings and their query behavior
2	Mappings and field types	Design one product or log mapping and list migration risks
3	Shards, replicas, routing, and refresh	Draw write and search paths with failure cases
4	Query DSL, filters, BM25, and pagination	Build a correct query and a small relevance judgment set
5	Aggregations and capacity	Bound buckets, fan-out, memory, and freshness trade-offs
6	Slow-query incident	Run the Terms → Topology → Trace → Trade-off loop aloud

Frequently asked questions

What Elasticsearch topics are most important for backend interviews?

Prioritize analysis, inverted indexes, mappings, text versus keyword, shards and replicas, routing, refresh semantics, query/filter context, BM25, aggregations, and incident debugging. For each topic, connect the mechanism to correctness, relevance, latency, indexing cost, recovery, and an observable production signal.

How deep should I go into Lucene internals?

Go deep enough to explain immutable segments, postings, positions, scoring inputs, refresh, and merge consequences. You rarely need class-level Lucene trivia. The useful boundary is whether an internal concept changes your mapping, query, shard, freshness, memory, or recovery decision.

Is adding more shards a good Elasticsearch performance fix?

Not by default. More primary shards can increase parallelism and future distribution, but they also increase fan-out, metadata, scheduling, cache, file, and recovery overhead. Measure shard size, document count, growth, hot-key skew, node capacity, and query concurrency before creating a new topology.

What is the biggest mapping mistake candidates make?

They choose a field type from the JSON value instead of the required access pattern. A string may need analyzed full-text search, exact matching, sorting, aggregation, or several of those through multi-fields. Strong answers also prevent unbounded dynamic keys and plan reindexing for incompatible changes.

When should I use the Profile API?

Use it on a representative query in a safe environment after other evidence narrows the problem to shard execution. Profiling adds significant overhead and does not measure network latency, queue time, or coordinating-node response merging. Pair it with request timing, logs, task data, hot threads, and resource metrics.

Final takeaway

The best Elasticsearch interview answers connect terms, topology, trace, and trade-off. Explain what was indexed, where the request executes, which evidence isolates cost, and how the change affects relevance, freshness, indexing, recovery, and capacity. Then practice the full reasoning loop against realistic Backend Engineer interview questions.