Top 50 Elasticsearch Interview Questions & Answers (2026)

Elasticsearch is a distributed, open-source search and analytics engine built on top of Apache Lucene. It solves the problem of fast full-text search and real-time analytics over large volumes of data — tasks that traditional relational databases handle poorly. Common use cases include application search (e-commerce product search), log and event data analysis (the ELK stack), and business intelligence dashboards. Elasticsearch can index millions of documents and return search results in milliseconds, making it the industry standard for search-heavy applications.

The ELK stack is a popular log management and analytics pipeline composed of three open-source tools: Elasticsearch stores and indexes the data, Logstash ingests, transforms, and ships data from various sources into Elasticsearch, and Kibana provides a browser-based UI for visualizing and exploring the data stored in Elasticsearch. A modern variant is the Elastic Stack, which adds Beats (lightweight data shippers) to the ELK trio. The stack is widely used for centralized logging, application performance monitoring (APM), and security analytics (SIEM).

In Elasticsearch, an index is the top-level data container analogous to a database in a relational system. It holds a collection of documents that share a similar structure. Before Elasticsearch 7.x, an index could contain multiple "types" (similar to tables), but types were removed in 7.x — each index now maps to a single logical document type. Unlike a relational database, an Elasticsearch index is schema-optional: you can store documents without defining a schema first, though defining an explicit mapping gives you fine-grained control over field types and indexing behavior.

A document in Elasticsearch is the basic unit of information that is indexed and searchable, analogous to a row in a relational database table. Documents are stored as JSON objects. Each document belongs to an index and has a unique _id. For example, a product document might look like {"name": "Running Shoes", "price": 59.99, "brand": "Nike"}. Documents are schema-flexible — different documents in the same index can have different fields, though this is generally discouraged for performance reasons. Documents are immutable once indexed; updating a document replaces it entirely internally.

A field in Elasticsearch is a key-value pair within a document, analogous to a column in a relational database. Each field has a name and a value, and its behavior during indexing and search is governed by its data type in the mapping — for example, text for full-text search, keyword for exact matching, integer, date, boolean, etc. Unlike a fixed column, a field can contain an array of values naturally in Elasticsearch (e.g., a tags field can hold multiple strings). Fields can also be nested objects or arrays of objects.

A cluster is a collection of one or more Elasticsearch nodes that together hold all your data. A node is a single server instance of Elasticsearch that belongs to a cluster. A shard is a subset of an index — Elasticsearch horizontally splits an index into multiple shards, each of which is a fully functional, independent Lucene index stored on a node. A replica is a copy of a primary shard stored on a different node. Replicas provide high availability (if a node fails, replicas take over) and improve read throughput (searches can be executed on replicas in parallel).

A shard is the fundamental unit of storage and scalability in Elasticsearch. When you create an index, Elasticsearch divides it into a configurable number of primary shards (default is 1 in ES 7+). Each shard is an independent Lucene index that can be hosted on any node in the cluster. Sharding matters because it enables horizontal scaling: adding more nodes allows shards to redistribute, increasing storage capacity and search throughput. However, the number of primary shards is fixed at index creation time, so you must plan shard count carefully upfront. The rule of thumb is 20–40 GB per shard.

Primary shards are the authoritative copies of your data. When you index a document, it is written to the primary shard first, then replicated to replica shards. Replica shards are copies of primary shards stored on different nodes. They serve two purposes: high availability — if the node holding a primary shard fails, Elasticsearch promotes a replica to primary automatically — and read scalability — search queries can be routed to both primary and replica shards, so more replicas means more search capacity. Note that replica shards require extra storage and must be on a different node than their primary.

You create an index in Elasticsearch using a PUT request to the REST API: PUT /my-index. You can optionally pass a JSON body with settings (number of shards and replicas) and mappings (field type definitions). For example: PUT /products { "settings": { "number_of_shards": 1, "number_of_replicas": 1 }, "mappings": { "properties": { "name": { "type": "text" }, "price": { "type": "float" } } } }. If you index a document into a non-existent index, Elasticsearch creates it automatically using dynamic mapping — though explicit creation is recommended in production for predictable behavior.

Elasticsearch exposes a REST API for all CRUD operations. Create/Index: POST /index/_doc (auto-generates an ID) or PUT /index/_doc/1 (explicit ID). Read: GET /index/_doc/1 retrieves a document by ID. Update: POST /index/_update/1 with a doc or script body performs a partial update. Delete: DELETE /index/_doc/1 removes a document. All responses are JSON and include metadata fields like _index, _id, _version, and result (created/updated/deleted).

The Query DSL (Domain Specific Language) is Elasticsearch's JSON-based language for defining search queries. Every search request body contains a query key whose value is a nested JSON object describing the query. The three most common leaf queries are: match (full-text search against text fields — the most frequently used), term (exact value match against keyword/numeric fields — no analysis), and range (matches documents where a field value falls within a specified range). Compound queries like bool combine multiple leaf queries with logical operators.

Full-text search uses text field type and the match query. The input text and the stored value are both run through an analyzer (tokenization, lowercasing, stemming, etc.) before comparison. This means searching for "Running Shoes" will match documents containing "run" or "shoe" depending on the analyzer. Exact match uses the keyword field type and the term query. No analysis is applied — the value must match exactly, including case and whitespace. Use keyword for structured data like IDs, status codes, email addresses, and categories.

An inverted index is the core data structure that makes fast full-text search possible. Instead of storing documents and scanning them one by one, an inverted index maps each unique term (word) to the list of documents that contain it. For example, the term "elasticsearch" might map to document IDs [1, 5, 12]. When you search for "elasticsearch", Elasticsearch looks up the term in the inverted index and instantly retrieves the matching document IDs — rather than scanning all documents. Each shard in Elasticsearch contains a Lucene index, which is essentially a collection of inverted indexes (one per field).

When Elasticsearch executes a full-text search query, it assigns each matching document a relevance score (the _score field) that represents how well the document matches the query. The scoring algorithm is BM25 (Best Match 25), the modern default replacing TF-IDF. BM25 considers term frequency (how often the search term appears in the document), inverse document frequency (how rare the term is across all documents — rare terms score higher), and field length normalization (shorter fields score higher). Results are returned sorted by score descending by default.

Elasticsearch is described as near-real-time (NRT) because there is a small delay (by default, 1 second) between when a document is indexed and when it becomes visible in search results. This delay is caused by the refresh interval: Elasticsearch buffers writes in memory and periodically writes them to a new Lucene segment, making them searchable. The default refresh_interval is "1s", which is usually imperceptible to users. You can force an immediate refresh with the ?refresh=true parameter on index/update/delete requests, though this should be avoided in high-throughput scenarios.

Kibana is the browser-based visualization and management UI for the Elastic Stack. It connects directly to Elasticsearch and provides tools for exploring data, building dashboards and visualizations (bar charts, line graphs, maps, heat maps), and running ad-hoc search and analytics queries through the Discover interface. Kibana also includes Lens (drag-and-drop dashboard builder), Maps for geo data, Machine Learning job management, APM (Application Performance Monitoring), and the Dev Tools Console — an interactive interface where developers can execute Elasticsearch REST API queries directly in the browser.

A mapping in Elasticsearch defines the schema for an index — it specifies how documents and their fields are stored and indexed. The mapping defines each field's data type (text, keyword, integer, date, boolean, geo_point, etc.) and indexing options (whether to store, analyze, or index the field). Unlike a relational database schema, Elasticsearch mapping is optional — if you do not define one, it uses dynamic mapping to automatically infer types from the first document indexed. However, auto-inferred mappings are often suboptimal, so explicitly defining mappings is strongly recommended in production.

Dynamic mapping is Elasticsearch's automatic type detection feature. When you index a document that contains a field not yet defined in the mapping, Elasticsearch infers the appropriate data type and adds it to the mapping automatically. For example, a JSON boolean becomes a boolean field, a number becomes long or float, and a string that looks like a date becomes date. Importantly, string fields that do not match a date pattern are mapped as both text (for full-text search) and keyword (for exact match/sorting/aggregations) by default. Dynamic mapping is convenient but can cause unexpected mappings — always validate in production.

An analyzer is a pipeline applied to text fields during indexing and search that transforms raw text into tokens stored in the inverted index. An analyzer consists of three components: a character filter (optional, pre-processes the raw text, e.g., stripping HTML), a tokenizer (splits text into tokens, e.g., the standard tokenizer splits on whitespace and punctuation), and one or more token filters (transform tokens, e.g., lowercase filter, stop word removal, stemming). The default standard analyzer tokenizes on whitespace/punctuation and lowercases. Choosing the right analyzer is critical for search quality.

In Elasticsearch, query context asks "how well does this document match?" — it calculates a relevance score for each matching document. Use query context for full-text search where ranking by relevance matters (e.g., match query). Filter context asks "does this document match?" — it is a yes/no decision with no scoring, and results are automatically cached. Use filter context for structured data like status, date ranges, and boolean flags. In a bool query, clauses inside must and should contribute to the score (query context), while clauses inside filter and must_not do not (filter context). Always put non-scoring criteria in the filter clause for better performance.

The bool query is the primary compound query in Elasticsearch used to combine multiple queries with logical operators. It has four clause types: must — the query must match and contributes to the score (AND); should — the query is optional but boosts the score if it matches (OR); must_not — the query must NOT match (executed in filter context, no score contribution); and filter — the query must match but does NOT contribute to the score and IS cached. For example, a product search might use must for the keyword match, filter for category and price range, and must_not to exclude out-of-stock items.

Aggregations are Elasticsearch's analytics framework — they allow you to compute summaries over your data alongside search results. Bucket aggregations group documents into buckets (e.g., terms aggregation groups by a field value like category, date_histogram groups by time intervals, range groups by value ranges). Metric aggregations compute numeric values over a set of documents (e.g., avg, sum, min, max, cardinality for approximate unique count). Aggregations can be nested: you can compute metrics within each bucket. They power Kibana dashboards and are executed server-side on the indexed data.

The text field type is analyzed — the stored value is run through an analyzer to produce tokens for the inverted index, enabling full-text search with relevance scoring. Text fields cannot be used for sorting or aggregations (without a sub-field). The keyword field type is NOT analyzed — the value is stored as-is for exact matching. Keyword fields support sorting, aggregations (e.g., terms aggregation), and filtering. For a field like "product name" where you want both full-text search and the ability to aggregate or sort, use a multi-field mapping: {"type": "text", "fields": {"keyword": {"type": "keyword"}}} — this is the default for dynamic string mapping.

Index templates automatically apply settings, mappings, and aliases to new indices when they are created, if the index name matches the template's index pattern. This is essential for time-series data where a new index is created every day (e.g., logs-2026-06-01). Component templates (introduced in ES 7.8) are reusable building blocks of settings and mappings that can be composed into index templates — promoting DRY (Don't Repeat Yourself) configuration. For example, you might have a component template with common ILM settings and another with standard log field mappings, combining them into multiple index templates for different log sources.

The Reindex API (POST /_reindex) copies documents from a source index to a destination index. The primary use case is zero-downtime index migrations: when you need to change a field mapping (e.g., change a text field to keyword), you create a new index with the correct mapping, reindex data from the old index to the new one while the old index continues serving traffic, then atomically switch an alias from old to new. Reindex also supports a query to copy only matching documents, a script to transform documents during copying, and cross-cluster reindexing. It can be slow for large indexes — use slices for parallel execution.

An alias is a secondary name that points to one or more indices, allowing you to decouple your application from the physical index name. For read/write separation, you can have a read alias pointing to multiple indices and a write alias pointing only to the current active index. The most powerful use case is zero-downtime reindexing: your application always reads/writes via the alias, so when you need to reindex, you atomically swap the alias from old to new with a single POST /_aliases call (no application code changes). Aliases can also include a filter query to create a virtual "view" of a subset of documents.

The Scroll API is designed for retrieving large numbers of results (thousands to millions) from Elasticsearch in batches, without the limitations of regular pagination. A regular search with from + size pagination becomes prohibitively expensive beyond from: 10000 because Elasticsearch must rank all matching documents up to that offset. With the Scroll API, the first request creates a "scroll context" (a snapshot of the search state) and returns a _scroll_id. Subsequent requests use this ID to retrieve the next batch. Use Scroll for bulk exports and data migration. For live, paginated UIs, use search_after instead — Scroll contexts consume significant heap memory.

search_after is the recommended pagination method for deep pagination in live search UIs. Unlike from + size which becomes expensive for deep pages, search_after uses the sort values of the last document on the current page as a cursor for the next page. You must include a sort clause with a unique tiebreaker field (like _id). The next page request passes the last document's sort values in the search_after array. This approach is stateless (no scroll context to maintain) and performs consistently regardless of how deep the page is. It is ideal for infinite scroll UIs and cursor-based pagination APIs.

The Highlight API returns snippets of text from matched fields with the search terms wrapped in HTML tags (by default <em>), so you can display context around the match in your search results UI — similar to how Google shows bold terms in search snippets. Add a highlight section to your search request: {"highlight": {"fields": {"content": {}}}}. The response includes a highlight object per document with arrays of highlighted snippets. You can customize the pre/post tags, the number of fragments, and the fragment size. Elasticsearch offers three highlighter implementations: unified (default), plain, and fvh (fast vector highlighter, requires term vectors).

In Elasticsearch, when you index an array of objects with the object type (the default), Elasticsearch flattens the inner objects — their field values are all merged into flat arrays. This means cross-field relationships between inner object properties are lost, leading to incorrect query results. For example, if you have products with multiple prices per region, a query "price > 100 AND region = US" might incorrectly match a document where one object has price > 100 but a different object has region = US. The nested type solves this by storing each inner object as a separate hidden Lucene document, preserving the relationship between fields. However, nested queries are slower and require the nested query wrapper.

A custom analyzer allows you to compose your own analysis pipeline by combining a tokenizer, character filters, and token filters to suit your specific search needs. Define it in the index settings under analysis.analyzer. For example, an autocomplete analyzer might use the edge_ngram tokenizer to generate prefix tokens (e.g., "ela", "elas", "elast") for fast prefix matching. A synonym analyzer might add a synonym token filter to map "laptop" to "notebook". A language-specific analyzer might use a stemmer and stop word filter for that language. Custom analyzers are one of the most powerful tools for improving search relevance and performance.

The percolator is a feature that inverts the normal search flow: instead of storing documents and querying them, you store queries in an index and then check which stored queries match a given document. This is called "reverse search" or "prospective search." Real-world use cases include: alert systems (notify a user when a new product matches their saved search), content tagging (automatically classify incoming articles), and news filtering (route new articles to subscribers based on their interests). You index queries using the percolate field type and then use the percolate query to find all stored queries that match a given document.

update_by_query (POST /index/_update_by_query) finds all documents matching a query and updates them using a Painless script, without retrieving them to the application first. For example, add a field to all documents where status: "active". delete_by_query (POST /index/_delete_by_query) finds all documents matching a query and deletes them in bulk. Both operations use a snapshot of the index state at the time of the request and process documents in batches. They can be throttled to reduce cluster load using the requests_per_second parameter. For large datasets, they can take a long time and should be run asynchronously using the wait_for_completion=false parameter.

Ingest pipelines allow you to pre-process documents before they are indexed, without needing Logstash for simple transformations. A pipeline is a sequence of processors that transform the document. Common built-in processors include: set (add/overwrite a field), remove (delete a field), rename (rename a field), grok (parse unstructured text with regex patterns), date (parse a date string into a date field), convert (change field type), and script (run a Painless script). Specify the pipeline during indexing with the ?pipeline=my-pipeline query parameter. Pipelines are ideal for log enrichment, IP geolocation, and data normalization.

Elasticsearch has first-class support for geospatial data. Fields mapped as geo_point can store latitude/longitude coordinates. The most common geo queries are: geo_distance (find all documents within a given radius of a point — e.g., "restaurants within 5km of me"), geo_bounding_box (find documents within a rectangular bounding box defined by top-left and bottom-right corners), and geo_polygon (find documents within an arbitrary polygon). Geo queries are typically used in filter context for performance. The geo_shape field type and query support complex geometries like polygons, lines, and multi-points for advanced GIS use cases.

Elasticsearch supports a rich set of field data types. String types: text (analyzed, for full-text search) and keyword (not analyzed, for exact match/aggregations). Numeric types: long, integer, short, byte, double, float. Date types: date (stores dates as milliseconds since epoch). Boolean: boolean. Geo types: geo_point (lat/lon) and geo_shape (complex geometries). Specialized types: ip (IPv4/IPv6 addresses with CIDR range query support), dense_vector (fixed-length float arrays for vector search / kNN), completion (for fast autocomplete suggestions), and binary (Base64-encoded binary data).

The join field allows you to define parent-child relationships between documents within the same index, enabling queries that span related document types. Unlike nested documents (which are separate hidden Lucene docs), parent and child documents are separate, individually updateable documents. A has_child query returns parent documents that have matching children, and a has_parent query returns children whose parent matches. The critical constraint is that parent and child documents must be on the same shard — enforce this by including the parent ID as the routing value when indexing children. Parent-child is useful for one-to-many relationships where children are updated frequently (e.g., a product catalog with frequently updated stock levels).

The Multi Search API (POST /_msearch) allows you to bundle multiple search requests into a single HTTP request, reducing network overhead. The request body alternates between a header line (specifying the index and search type) and a body line (the search request JSON). This is useful for dashboards that need to execute many independent queries simultaneously — instead of making 10 separate HTTP requests, you make one. The response contains an array of results, one per query. Kibana uses msearch extensively to populate its dashboards efficiently. Note that all queries still execute concurrently on the cluster, so it does not reduce cluster CPU load, only client-server network round trips.

Elasticsearch reports cluster health as green, yellow, or red. Green means all primary and replica shards are allocated and active — the cluster is fully operational. Yellow means all primary shards are allocated (data is safe, all search and indexing works), but one or more replica shards are unallocated — typically because you have a single-node cluster and replicas cannot be placed on the same node as their primary. Red means one or more primary shards are unallocated — the cluster is missing data and those shards cannot be searched or written to. Red status triggers immediately when a node goes down before its primary shards' replicas can be promoted. Use GET /_cluster/health?level=shards to identify which specific shards are problematic.

The hot-warm-cold architecture is a tiered storage strategy for time-series data (logs, metrics, events) that matches node hardware to data access patterns, reducing cost without sacrificing performance. Hot nodes hold the most recent, most-queried data on fast SSD storage with high CPU and RAM — these handle all writes and the majority of reads. Warm nodes hold older, less-frequently queried data on larger, slower (spinning disk) storage. Cold nodes hold rarely accessed historical data, often with frozen indices that are mounted from snapshots on object storage (S3) and only loaded on demand. Shard allocation filtering (_tier_preference) controls which tier an index lives on, and ILM policies automate the migration between tiers as data ages.

Index Lifecycle Management (ILM) automates the management of time-series indices through a configurable policy with up to five phases: Hot (active writing and querying — can trigger rollover when the index exceeds a size or document count threshold), Warm (no longer written to — shard allocation moved to warm tier, force-merged to reduce segment count, replicas may be reduced), Cold (infrequently accessed — moved to cold tier, possibly made searchable-only), Frozen (data mounted from snapshot repository, minimal memory footprint, slow query times), and Delete (the index is permanently removed). ILM policies are attached to index templates, so every new index created by that template automatically follows the lifecycle. This is essential for managing growing log and metrics data without manual intervention.

Cross-Cluster Replication (CCR) continuously replicates indices from a leader cluster to one or more follower clusters. It enables disaster recovery (automatic failover to a replica cluster in another data center), geo-proximity (replicate data to a local cluster to reduce search latency for users in different regions), and centralized reporting (aggregate data from multiple regional clusters into a single reporting cluster). Cross-Cluster Search (CCS) allows a single search query to transparently execute across multiple clusters and return merged results. With CCS, you can search cluster1:logs-*,cluster2:logs-* in one query. CCS is useful for federated search across multiple independent Elasticsearch clusters without physically consolidating data.

function_score wraps a query and modifies document scores using one or more scoring functions. Built-in functions include weight (multiply score by a constant), field_value_factor (use a document field value to boost score — e.g., boost by popularity count), gauss/linear/exp decay functions (score decays as a field value moves away from an origin — great for "freshness" or "proximity" boosts), and random_score (consistent random ordering per user session). script_score (simpler, ES 7+) wraps any query and allows you to write a Painless script to compute a new score from scratch using any document fields and the original _score. Use these for e-commerce ranking that combines textual relevance with business metrics like sales rank or margin.

Key hardware and JVM tuning rules for Elasticsearch: Heap size — set the JVM heap to 50% of available RAM, with a maximum of 30–31 GB (above this, the JVM switches from compressed object pointers to full 64-bit pointers, wasting memory). The remaining 50% is used by the OS for the Lucene file system cache, which is critical for performance. Storage — use SSDs for hot data; spinning disks cause severe latency for random I/O. Disable swap — swapping Elasticsearch heap to disk causes extreme latency; use bootstrap.memory_lock: true and set ulimit -l unlimited. File descriptors — set to at least 65536. Virtual memory — set vm.max_map_count=262144 for Lucene's use of memory-mapped files.

Several techniques improve indexing throughput significantly. Use the Bulk API (POST /_bulk) to send multiple index/update/delete operations in a single request — aim for 5–15 MB per bulk request batch. Increase refresh interval: set refresh_interval: "30s" or -1 (disable) during initial bulk loads, then restore to "1s" — each refresh triggers a Lucene merge, so reducing frequency dramatically cuts write overhead. Disable replicas during initial load: set number_of_replicas: 0 during bulk indexing, then restore — Elasticsearch won't replicate each document during the load. Use multiple indexing threads/clients to saturate all shards in parallel. After bulk indexing, call POST /index/_forcemerge?max_num_segments=1 to consolidate segments and improve query performance.

Circuit breakers are memory protection mechanisms in Elasticsearch that prevent operations from causing an OutOfMemoryError by estimating memory usage before allocating it and rejecting the request with a CircuitBreakingException (HTTP 429) if it would exceed configured limits. Key circuit breakers include: Field data circuit breaker (limits memory used by loading field data for aggregations and sorting — default 40% of heap), Request circuit breaker (limits memory for a single search request, including aggregation data structures — default 60% of heap), In-flight requests circuit breaker (limits memory for all currently in-flight requests — default 100% of heap), and the parent circuit breaker (overall limit across all child breakers — default 95% of heap). Monitor circuit breaker trips in logs and DevTools as they indicate memory pressure.

Elasticsearch 8.x introduced native kNN (k-Nearest Neighbor) vector search using the dense_vector field type and the knn query parameter. This enables semantic search and AI-powered retrieval: documents are represented as high-dimensional vectors (embeddings generated by ML models like BERT or OpenAI's text-embedding models), and search finds the k documents whose vectors are closest to the query vector by cosine similarity or dot product. Use cases include semantic document search (finding conceptually similar documents even without keyword overlap), image similarity search, recommendation systems, and anomaly detection. Elasticsearch implements approximate kNN using the HNSW (Hierarchical Navigable Small World) algorithm for efficient similarity search at scale. Combine kNN with bool filters for hybrid search (semantic + keyword).