Elasticsearch is best understood not as just another database, but as a separate search layer with its own indexing model, update lag, and operational risks.
In real work, this chapter helps you think early about sharding, index templates, rollover, reindex workflows, and near-real-time behavior so search does not become fragile magic on top of the main store.
In interviews and architecture discussions, it is especially valuable when you need to explain why a system needs a dedicated search layer and why it cannot be merged painlessly with the transactional source of truth.
Practical value of this chapter
Search boundary
Keep the search index separate from the transactional source of truth: Elasticsearch accelerates discovery but is not the system of record.
Index lifecycle
Plan index templates, rollover, retention policy, and reindex workflows before launch.
Relevance and latency
Align analyzers, ranking strategy, and caching with UX expectations and query traffic patterns.
Interview framing
Explain why a dedicated search tier is introduced and what consistency risks come with it.
Source
Wikipedia: Elasticsearch
Project history, baseline architecture, and Elasticsearch’s role in the search ecosystem.
Official site
Elastic: Elasticsearch
Product documentation, platform capabilities, and operational guidance.
Elasticsearch is a distributed search and analytics engine built on Apache Lucene. In system design it is usually used as a dedicated search layer over a transactional database: this enables fast full-text queries and filtering, but requires deliberate work with indices, consistency, and operational cost.
History and context
Project launch
Elasticsearch is created as a distributed REST engine built on top of Apache Lucene.
ELK ecosystem emerges
Search, log pipelines, and visualization tools start being used together as one operating stack.
Enterprise adoption grows
The platform becomes widely used for log analytics, observability, and product search.
Licensing and cloud evolution
Cloud offerings and operational practices for high-load clusters continue to evolve.
Core architecture elements
Index, shards, and replicas
An index is split into primary shards, and replicas are added for fault tolerance. This is the foundation of horizontal scaling.
Cluster and node roles
The cluster coordinates query execution, data placement, and shard rebalancing across nodes.
Near real-time search
Data is not instantly searchable: it becomes visible after refresh cycles, creating a trade-off between freshness and throughput.
Relevance and ranking
BM25 and text-analysis settings help rank results and tune search quality.
Elasticsearch architecture by layers
The diagram below shows a baseline Elasticsearch setup in a product system: a dedicated search layer, indexing pipeline, and a cluster with primary and replica shards.
system view
Elasticsearch is usually deployed as a dedicated search and analytics layer over a transactional source of truth.
Search quality
Analytics
Operational trade-offs
Write and read paths through components
The interactive flow below shows how documents move into the index and how queries travel through a coordinating node and shards before returning ranked results.
Write and read paths
Interactive view of how requests move through core Elasticsearch components.
Write path
- A service writes the event to the source of truth (typically an OLTP database).
- Through CDC/outbox or an ingestion pipeline, the document reaches the indexer.
- Elasticsearch places the document into a primary shard and replicates it to replicas.
- After refresh, the document becomes visible in search results (near real-time).
When to choose Elasticsearch
Good fit
- Full-text product search (catalogs, articles, documentation).
- Observability scenarios: search over logs, events, and traces.
- Use cases that need flexible filters, aggregations, and ranking.
- Read-heavy systems that require fast search experience.
Avoid when
- As the only source of truth for critical transactional data.
- OLTP workloads with frequent point updates/deletes and strict ACID expectations.
- Systems without full-text search needs where SQL/cache is enough.
- Teams not ready for cluster and index operational overhead.
Practice: DDL and DML
Below are practical API examples often discussed in system design interviews: from index/mapping management to document writes and search queries.
DDL and DML examples in Elasticsearch
DDL controls indices and mappings, while DML operates on documents and search queries.
DDL in Elasticsearch is about schema and index lifecycle operations: creating indices, tuning shards/replicas, and evolving mappings.
Create an index with settings and mapping
PUT /products-v1Define shard/replica layout and field types before indexing data.
PUT /products-v1
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
},
"mappings": {
"properties": {
"name": { "type": "text" },
"price": { "type": "float" },
"category": { "type": "keyword" },
"created_at": { "type": "date" }
}
}
}Add new fields to existing mapping
PUT /products-v1/_mappingYou can extend mapping with new fields (changing existing field types is limited).
PUT /products-v1/_mapping
{
"properties": {
"brand": { "type": "keyword" },
"is_active": { "type": "boolean" }
}
}Alias switch for zero-downtime reindex rollout
POST /_aliasesBlue/green pattern: move alias from products-v1 to products-v2 atomically.
POST /_aliases
{
"actions": [
{ "remove": { "index": "products-v1", "alias": "products" } },
{ "add": { "index": "products-v2", "alias": "products" } }
]
}Related chapters
- Search System (Google/Elasticsearch) - Practical system design case on ranking, indexing, and scaling a production-grade search platform.
- Database Selection Framework - How to decide when a search engine should be introduced as a dedicated layer next to the transactional datastore.
- MongoDB: document model, replication, and consistency - Boundary between an operational document store and a full-text search index in real-world architectures.
- ClickHouse: analytical DBMS and architecture - Separation of concerns between full-text retrieval and analytical aggregation over event data.
- Qdrant: vector database and architecture - Lexical search versus vector retrieval trade-offs for semantic and AI-oriented discovery scenarios.
- Data Pipeline / ETL / ELT Architecture - How to build ingestion and index-synchronization pipelines that keep search data fresh under continuous updates.