# Elasticsearch for system design interviews > Elasticsearch is a distributed search and analytics engine built on Apache Lucene. Use it for full-text retrieval, ranked results, filters, and aggregations, usually as a searchable projection of data stored in a primary database. Source: https://sysround.com/tech/elasticsearch Updated: 2026-11-05 ## How it works An Elasticsearch cluster contains nodes that store data and coordinate requests. An index is divided into primary shards, each of which is a Lucene index, with optional replica copies. Elected master nodes manage cluster metadata, shard allocation, and membership, rather than coordinating every search or write. A coordinating node routes a document write to its primary shard using a hash of the routing value, which defaults to the document ID. The primary validates and applies the operation, then forwards it to in-sync replicas. With the default request-level translog durability, acknowledgment waits for the relevant translogs to be persisted on the primary and participating replicas. Lucene analyzes text into terms and stores an inverted index that maps terms to matching documents. Keyword fields support exact matching, while doc values provide a column-oriented representation for sorting and aggregations. Explicit mappings keep field types and analyzers predictable. Writes become searchable after a refresh opens a new searcher over recent changes. Refresh is different from an Elasticsearch flush, which creates a Lucene commit and advances the translog lifecycle. Lucene stores immutable segments and merges them in the background; updates generally mark the old document deleted and index a replacement. For a typical distributed search, the coordinating node sends the query to one copy of each relevant shard. Shards return local top matches, the coordinator merges them, and a fetch phase retrieves the requested document fields. More shards increase parallelism but also increase fan-out, coordination work, and exposure to slow shards. ## What it gives you in a design - **Full-text relevance.** Analyzers, tokenization, stemming, synonyms, and BM25 scoring support ranked text retrieval. Analyzer choices are part of the data model, and changing index-time analysis generally requires reindexing. - **Structured and geographic filtering.** Combine text queries with exact values, ranges, and geographic constraints. This fits designs such as restaurant discovery or marketplace search, where relevance alone is not enough. - **Aggregations.** Compute buckets, metrics, and facets alongside search results. High-cardinality buckets and large distributed aggregations can consume substantial memory, and some results are approximate or affected by shard-level candidate selection. - **Bulk ingestion.** The bulk API reduces per-document request overhead. Each item has its own result, so ingestion workers must inspect failures and retry only the appropriate operations. - **Aliases and index lifecycle management.** Aliases provide a stable application-facing name while backing indexes change. Rollover and lifecycle policies help manage time-based data, retention, and movement between storage tiers. - **Stable deep pagination.** A point in time combined with search_after supports pagination without repeatedly collecting every earlier result. Use a deterministic sort with a tie-breaker and bound the lifetime of retained search contexts. - **Vector and hybrid retrieval.** Elasticsearch can combine vector similarity with keyword retrieval. Explain embedding generation, metadata filtering, and recall-versus-latency trade-offs rather than assuming vector search replaces text search. ## Scaling, replication and failure Choose shard counts around data volume, query fan-out, indexing load, and recovery time. Adding nodes does not automatically increase an existing index's primary shard count. Splitting under supported conditions or reindexing can change partitioning, but both require planning and spare capacity. Replicas provide additional search capacity and failover copies, but they also increase storage and indexing work. Elasticsearch normally places a primary and its replicas on different nodes; allocation awareness can spread copies across failure zones. Replicas do not replace snapshots because accidental deletions and bad updates replicate too. Search is near real time, not immediately consistent with acknowledged writes. A real-time document GET has different visibility behavior from search. On primary failure, an eligible in-sync replica can be promoted; without an available primary, writes to that shard cannot proceed, and unavailable shards can cause searches to fail or return explicitly marked partial results. Custom routing can reduce query fan-out when most requests target one tenant or entity, but large tenants can create hot shards. For database-backed search, use CDC or an outbox-driven pipeline, deterministic document IDs, and source versions to handle retries and out-of-order updates. Track indexing lag and define how the system behaves when search falls behind. ## Limits and defaults worth knowing - **Default shard configuration:** Modern Elasticsearch defaults to 1 primary shard and 1 replica per index unless settings or templates override them. A single-node cluster cannot allocate the replica alongside its primary. - **Search refresh interval:** Elastic Stack defaults to a 1-second refresh interval for indexes receiving searches, with idle-index behavior affecting automatic refreshes. Elasticsearch Serverless defaults to 5 seconds; settings and allowed values depend on deployment. - **Result window:** index.max_result_window defaults to 10,000, limiting from plus size for ordinary pagination. It is configurable, but raising it increases resource costs; use search_after with a point in time for deep pagination. - **Document ID length:** The _id field is limited to 512 bytes. Use a bounded identifier rather than placing arbitrary source content in the ID. - **Active shards before writes:** wait_for_active_shards defaults to 1, requiring an active primary before a write starts. This is an admission check, not a configurable quorum acknowledgment rule or a guarantee that every configured replica receives the write. ## Use it when - The design needs ranked keyword search, language-aware matching, or relevance tuning beyond simple database predicates. - Users combine text search with filters, geographic constraints, sorting, or facets. - The primary database should remain optimized for transactions while a separate index serves discovery queries. - Search visibility can lag behind committed source data, with an explicit freshness target and recovery process. - Logs or other event documents need interactive search and aggregations with bounded retention. ## Avoid it when - The core operation requires multi-record transactions, strict inventory enforcement, or authoritative financial balances. - The workload is mostly simple primary-key lookups that a database or cache can serve more cheaply. - Every committed write must appear immediately in every search, with no tolerance for refresh or ingestion lag. - The design depends on frequent relational joins or large cross-entity updates that would require extensive denormalization. ## What interviewers ask about it ### How do you keep Elasticsearch synchronized with the primary database? Commit changes to the source database and capture them through CDC or a transactional outbox rather than making independent dual writes. Apply events with deterministic IDs and source-order protection, and support backfills plus reconciliation because retries alone do not detect every missing document. ### What does an acknowledged write guarantee? With default request-level durability, acknowledgment includes translog persistence on the primary and participating replicas, but it does not mean the document is searchable yet. Replica failures can change the in-sync set, and wait_for_active_shards only controls the prerequisite for starting the write. ### How would you choose the number of shards? Estimate indexed data size, indexing rate, query concurrency, and recovery requirements, then test representative workloads. Too few shards limit distribution, while too many create small indexes, metadata overhead, and expensive search fan-out. ### How do you prevent stale permissions from leaking search results? Treat indexed permissions as a retrieval optimization, not necessarily the final authorization authority. For strict revocation, validate current access before returning content and account for stale snippets, counts, caches, and result pages. ### How do you change an incompatible mapping without downtime? Create a new index with the desired mapping, backfill it, and replay or continuously apply source changes while the backfill runs. Verify coverage and catch-up before atomically switching an alias, keeping a rollback plan that accounts for writes after cutover. ### What happens when a shard is slow or unavailable? A distributed query can be delayed by its slowest participating shard, so inspect per-shard latency, hot routing keys, merge pressure, and expensive queries. Define timeouts and partial-result policy explicitly, since a successful HTTP response does not necessarily mean every shard contributed. ## Common mistakes - Treating refresh, flush, translog persistence, and replication as the same event, then promising immediate search visibility after a write. - Adding many shards or replicas without explaining query fan-out, heap overhead, indexing costs, and recovery behavior. - Using independent database and Elasticsearch writes without a durable change pipeline, version checks, and a rebuild strategy. - Using stale search results as authoritative proof of permissions, inventory availability, or current listing state. ## Alternatives - **PostgreSQL full-text search:** Wins when search is modest in scope and keeping transactional data and search in one database avoids unnecessary synchronization and operational work. - **OpenSearch:** Fits similar distributed Lucene-based search workloads when its licensing, managed-service options, or ecosystem better match the deployment. Check feature and API compatibility rather than assuming complete interchangeability. - **Apache Solr:** Fits Lucene-based search when the team already operates Solr or prefers its search configuration and ecosystem. It still requires explicit shard, replication, and indexing-pipeline design. - **ClickHouse:** Wins for scan-heavy analytical queries and aggregations over large structured event datasets when ranked full-text retrieval is not the primary requirement. ## Interview questions where it comes up - [Design Facebook post search](https://sysround.com/questions/design-facebook-post-search): Elasticsearch supports distributed keyword retrieval, while the design must handle indexing freshness, relevance, and permission revocation. - [Design a restaurant review app like Yelp](https://sysround.com/questions/design-yelp): Text relevance, geographic filters, and facets support restaurant discovery, with review edits propagated from authoritative storage. - [Design Facebook Marketplace](https://sysround.com/questions/design-facebook-marketplace): A search projection supports filtered listing discovery while current availability and authorization remain authoritative elsewhere. - [Design Wikipedia or Notion](https://sysround.com/questions/design-wikipedia): Document search benefits from language-aware indexing, but page updates and inherited permission changes require careful synchronization. - [Design a distributed tracing system](https://sysround.com/questions/design-distributed-tracing): Indexed trace attributes support investigative search, with retention, field cardinality, and ingestion costs shaping the storage design. ## FAQ ### How does Elasticsearch architecture work? Elasticsearch distributes indexes across primary shards and replica copies, with each shard implemented as a Lucene index. A coordinating node routes writes to primaries and distributes searches across relevant shard copies, then merges their results. Master-eligible nodes manage cluster coordination and metadata. ### What is the difference between an Elasticsearch shard and a replica? A primary shard owns a partition of an index's documents. A replica is another copy of that shard that can serve searches and become primary after a failure. Adding replicas does not divide the index into more primary partitions. ### Can Elasticsearch be used as a primary database? It can hold durable documents, but its transaction model and near-real-time search visibility differ from those of a transactional database. For designs involving payments, inventory, or complex relational constraints, keep authoritative state elsewhere and build Elasticsearch as a recoverable search projection. ## Related concepts - [Inverted index](https://sysround.com/concepts/inverted-index) - [Full-text search](https://sysround.com/concepts/full-text-search) - [Database sharding](https://sysround.com/concepts/database-sharding) - [Database replication](https://sysround.com/concepts/replication) - [Change data capture](https://sysround.com/concepts/change-data-capture) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.