Jan Mikoláš
Glossary
Elasticsearch
Elasticsearch searches and evaluates data quickly over a prepared index. It is not usually the source of truth for orders, prices, or inventory.
Short definition
A search index alongside the main database.
Elasticsearch accepts documents, prepares them according to a mapping for specific queries, and can combine full-text search, exact filters, and aggregations. In an online store, that can mean product search, autocomplete, brand and parameter filters, or result counts.
It is not a general replacement for a relational database. A search document is usually a denormalized view assembled from data stored elsewhere. During an index outage, delayed synchronisation, or a mapping change, the application must know which data is authoritative and how to rebuild the index safely.
Use cases
When a search index solves a specific problem
It provides the most value where a database query is not enough for the expected search, filtering, or analytics.
- full-text search over products, categories, documents, or internal records
- autocomplete and typo tolerance tailored to the particular search
- catalogue filtering by brand, parameters, price, and availability
- facets and aggregations, such as product counts for individual filters
- searching logs, events, and operational data in near real time
Practical example
A catalogue with full-text search, filters, and availability
An online store builds a document for every product containing its name, description, brand, categories, parameters, price, and availability. The name and description are text fields with an analyzer; the brand and codes have a keyword variant. The query “running shoes” sorts by relevance, the brand filter uses keyword, and an aggregation returns size counts.
A product change occurs in the main database first. A worker then builds a new document from the event. When indexing is delayed, search results can differ from the detail page; the price and inventory are therefore verified in the authoritative system when the product is added to the cart.
Data flow
From a product change to a search result
The index is a separate view of the data. Reliability depends on both safe delivery of changes and the document design.
- Source of truth The product, price, and inventory change in the authoritative database; a transaction protects the business state.
- Delivering the change An outbox, queue, or import delivers a ProductChanged event to an indexing worker.
- Indexing The worker loads the data, builds a document, and writes it to the index according to the mapping.
- Refresh and search After a refresh, the changes become searchable. A query with filters and ordering returns documents and aggregations.
- State verification A product detail or purchase operation can verify the price, availability, and permissions in the authoritative system.
Important concepts
A document, mapping, and query play different roles.
Result quality begins with the data model and user expectations, not with choosing a single query.
Index and document
An index groups documents with a similar purpose. A document is a JSON view intended for search; it does not need the same shape as database tables or a public API response.
Mapping: text and keyword
A mapping defines a field’s type and indexing method. text is analysed for full-text search, while keyword retains the exact value for filtering, sorting, or aggregation. One field therefore often needs both representations.
Analyzer and inverted index
An analyzer splits and normalizes text into tokens. The inverted index then maps tokens to documents. Language, synonyms, and analyzer settings affect what users find.
Query, filter, and aggregation
A full-text query generally calculates relevance. A filter applies an exact condition, such as brand or availability. An aggregation counts results in groups.
Shard, replica, and refresh
An index is divided into shards distributed across nodes; replicas support reads and availability. A refresh makes recent writes searchable but does not confirm a business transaction.
Benefits and limitations
Fast search at the cost of an additional synchronisation and operational workflow.
Benefits
- full-text search, filters, relevance, and aggregations over one search model
- fast catalogue and autocomplete responses without complex database queries
- scaling search through shards and replicas
Risks
- synchronisation delays create differences from the source of truth
- an unsuitable mapping is often corrected by creating a new index and reindexing
- too many shards, fields, or analysed data increase operating costs
- relevance must match the user’s task and be measured against real queries
Scope of use
First determine whether the problem is really search.
Elasticsearch makes sense for a larger catalogue, relevance-based text search, or a combination of filters and aggregations. A well-designed SQL query may be simpler for a few precisely indexed attributes. The decision depends on volume, expected response time, query types, and the cost of stale results.
The index should not be the only state for an order, payment, or inventory reservation. A more complex integration therefore needs idempotent indexing, traceability of failed changes, and a safe process for complete reindexing.
What to keep in mind
Model the data and index recovery before production.
Search is both a product feature and a separate operational dependency.
- mappings, analyzers, and queries verified against real data and user languages
- a source of truth, synchronisation flow, and defined behaviour during delayed indexing
- idempotent indexing, error records, and the ability to reindex selectively or completely
- measuring latency, error rates, shard sizes, disk capacity, and cluster health
- restricted cluster access, a verified client, and no unnecessary copies of sensitive data in documents
Common questions
What Elasticsearch does and does not solve
Is Elasticsearch a database?
It stores documents and has its own persistence, but its usual role is a search and analytics index. An authoritative store must be chosen deliberately for transactional business data.
Why isn’t storing a product as one JSON document enough?
Merely storing JSON does not create full-text search. The mapping and analyzer determine search, filters, ordering, and aggregations.
Is new data searchable immediately?
Not necessarily. Elasticsearch exposes writes after a refresh, and delays can arise earlier while delivering the change to the index.
Does Elasticsearch replace an online store’s relational database?
Not automatically. Orders, payments, inventory reservations, and their rules need transactions and constraints. The index is suitable for search and a derived view of that data.
How I work with e-commerce systems
I design search together with the catalogue, pricing, and data flow.
For e-commerce applications, I assess how product data changes, which filters people actually use, and where the system must verify the current state.