Setting Up Elasticsearch for Search in a Mobile App

Elasticsearch for a mobile app: where search breaks

Search in an app is rarely designed in advance: usually it grows out of the request to “find a substring in the title” in the primary database. While the catalog has hundreds of items and one server, this works unnoticed.

As soon as the assortment grows and there are more users, search becomes a bottleneck that slows down both the catalog and checkout.

First point of failure — search relevance. Exact-match search doesn't find a product if there's a typo, different word order, or case: “men's sneakers” is found, “men's running sneakers” is not.

Elasticsearch addresses this by parsing the query into word forms, synonym dictionaries, and fuzzy matching — but only when analyzers, field weights, and priority rules are configured for a specific catalog rather than left at defaults.

Second point of failure — suggestions and autocomplete. Every keystroke sends a request, and the queue grows faster than the catalog. Slow search is immediately visible here: the user types a word, gets no suggestions, and closes the app.

Third — load on the backend. Search queries compete for the same resources as transactions and payment: heavy substring selections take power away from what should respond instantly, and the entire app slows down.

That is why search is moved to a separate layer — let's break down exactly where it breaks and how that is addressed.

Effect of reworking the search layer: speed and accuracy

Before rework, search in the app was performed by queries to the primary database: every character entered generated a selection across several tables with pattern comparison.

At peak loads, such queries competed with checkout operations, search response time grew to seconds, and some requests timed out — the user saw an empty screen instead of results.

The search layer was moved to Elasticsearch and separate indexes were built for products, categories, and suggestions. Indexes are updated by catalog change events, full reindexing runs in the background and does not block serving.

Response time dropped by an order of magnitude and stopped depending on catalog size: what used to degrade as the assortment grew now holds steady.

Search accuracy increased through three mechanisms.

Autocomplete shows options from the first characters entered, typo correction catches queries with keyboard-layout errors and missing letters, and a synonym dictionary brings different formulations of the same product to a common result.

The share of relevant results in the top ten grew from two-thirds to almost full — we calculate it on a labeled sample of real queries, not on test scenarios.

A separate effect is the load removed from the primary database. Search queries no longer reach it, so peak spikes are served without checkout degradation.

An entire class of failures is gone: empty results and timeouts during sales and at the moment of mailings, which previously had to be handled by manual scaling.

The search layer absorbs the spike itself, and when suggestions are unavailable, results continue to work in a reduced mode instead of a complete failure.

Options for organizing search: Elasticsearch and alternatives

Search in an app is almost never built on one technique: the choice depends on catalog size, relevance requirements, and how tolerant the app is to response latency. Below are four working options that are actually chosen between, and their limitations.

The schemes are compatible and allow migration: search is hidden behind a single app interface.

Starting with queries to the database, adding a suggestion cache, and moving to a separate search service do not require rewriting the client — only the implementation behind the interface changes.

Indexing runs asynchronously from the primary database, so search remains operational while a new index is being built.

Implementation stages: from query audit to handover

Search in an app most often breaks not when the engine is connected, but at the junction: the phrases people enter do not match how the data is labeled. That is why we proceed sequentially, and each stage ends with an artifact that can be verified before moving to the next.

1. Query audit. We collect real search phrases from logs and label them by scenario — catalog, autocomplete, typos and keyboard layout, repeated queries. The output is a map of bottlenecks: where results are empty, where relevance fails, where the user leaves after the first page.
2. Index schema. We design the structure for this labeling: which fields are text, which are filterable, where synonyms, morphology, and typo parsing are needed. Separately, we decide what to store in the index and what to pull from the primary database so the data does not diverge.
3. Serving setup. Language analysis, field weights, ranking rules by category, pagination, and suggestions. We describe and version the relevance logic — Elasticsearch is the executor here, not the source of rules.
4. Traffic validation. We enable the new serving for a portion of real users and compare it with the previous one: share of queries with a click into the product card, position of the target product, response time. We make the decision on full rollout based on numbers, not impressions.
5. Observability. We configure metrics and alerts: share of empty results, indexing errors, update lag. This is early warning instead of user complaints.
6. Support handover. We hand over configurations in repositories, schemas, reindexing and rollback instructions, and conduct a walkthrough with the customer's team. Done when synonyms and rules can be changed without us.

Configurations, index schemas, and support regulations

The search we configure is handed over with a complete set of artifacts — not a “black box,” but a set of configurations and rules by which the system can be developed and maintained in-house. Below is what exactly remains with your team after delivery.

• Index schemas — field mappings and analyzer settings for morphology, typos, and transliteration, with an explanation of why each field is stored the way it is.
• Data update rules — what goes into the index and how often, how deletions and partial failures are handled, how full reindexing is performed without downtime.
• Environment configurations — parameters for development, testing, and production environments with clearly described differences.
• Support regulations — what to do when the catalog grows, the card structure changes, and the engine is updated on schedule.
• Search monitoring — share of queries with no results, response time, share of queries with a transition to order, and alert thresholds.
• Backup and rollback — full and incremental index copies, recovery procedure, and time to return search to a working state.
• Documentation — deployment from scratch, a map of typical failures, and the points to look at first during degradation.

Each item is verified at acceptance: we show how to bring up the environment from scratch according to the documentation and reproduce the configuration.

Such a set means that search in the app can be developed and maintained without us — or together with us when the scope of work grows.

Case study: how catalog search sped up after rework

A catalog with several tens of thousands of items is the case where search stops being a secondary function.

In a service with a broad assortment, queries went directly to the primary database: every character entered generated a heavy query across the entire product table, suggestions returned in 1.5–2 seconds, and the needed product appeared in the top five in only 38% of queries.

The cause was not only speed. Search did not understand typos, word forms, synonyms, or Latin keyboard layout, and it surfaced discontinued items above current ones. Support received a stream of requests saying “the product exists, but search doesn't find it.”

What we did

We moved search into a separate index on Elasticsearch — the primary database stopped being a bottleneck, and ranking became manageable. We configured analyzers for Russian and Latin input: word forms, synonyms, transliteration, resilience to typos and extra spaces.

We added boosting by stock availability, popularity, and recency so that rare and discontinued items would not rise above bestsellers.

Operations were covered separately: the index is updated incrementally when the catalog changes, without a full rebuild, and if search is unavailable, the app serves cache and standard categories instead of an empty screen.

Metrics before and after

The switch happened without stopping the service. A month later, search stopped being a place that was scary to enter: users search directly more often instead of browsing categories, and the share of sessions with a search query grew without any changes to the interface.

What to do if search is already deployed in-house

If search already works on built-in tools — direct database queries or a local on-device index — you should start not with rewriting, but with measurements.

We look at the catalog volume at which response time stops fitting into the comfortable range, how results behave with typos, synonyms, and keyboard layout changes, and what happens to the database under peak load. These numbers determine whether a separate search service is needed at all.

Next, we split functionality by requirements. Input suggestions, filters, sorting, and full-text search with ranking are different tasks, and some of them can safely remain on built-in search.

Usually only the full-text scenario is worth moving out, where relevance, morphology, and resilience to input errors matter — the rest should not be touched.

We migrate to a search service such as Elasticsearch without downtime: indexes are populated in parallel with the app's operation, the old environment continues to serve users, and the new one receives the same data stream and responds in shadow mode.

We compare results on the same set of queries until discrepancies are explained, and only then do we switch a share of traffic — first to internal employees, then to a small percentage of the audience.

Your team does not switch off in the process: it owns domain logic, data processing rules, and ranking priorities, while we cover the index schema, replication, reindexing, and failure behavior.

Rollback means returning the traffic share and the old environment, which remains live until the new metrics are stable. That is why migration without downtime is not a promise but a consequence of the two schemes running simultaneously for some time.

Technical doubts: questions from engineers and tech leads

Doubts about Elasticsearch in a mobile app come down to five topics: data freshness in the index, behavior when the search service fails, measurability of result quality, volume growth, and support after handover. Let's break down each one.

What will the user see if search fails?

Several nodes with shard replicas — losing one does not interrupt serving. If all search is unavailable, the app falls back to a reserve path: a database query by key fields with basic filters instead of an error screen.

How do you validate result quality?

Before release, we run a reference set of queries with expected results and calculate recall and precision. In production, we look at queries without clicks and reformulations: if they grow, we adjust the analyzer, synonyms, and field weights.

Will search withstand data volume growth?

Shards are split by time and content type: catalog growth does not require full reindexing. Old data moves to a cold index with fewer replicas, and a lifecycle policy cleans it up automatically.

Can we maintain search in-house?

We hand over mappings, analyzers, lifecycle policies, monitoring dashboards, and alerts, and walk the team through typical operations: add a field, reindex, change ranking. After that, you run the environment yourselves.

Let's discuss the task: we'll review the search scheme and come back with a plan

A conversation about search quickly turns into generalities if you come to it without facts.

To discuss the task concretely, what already exists in the project is enough: descriptions of the current index scheme, exports of real user queries, examples of successful and unsuccessful results, personal data restrictions, and the points where the app calls the search service.

• search scenarios: suggestions as you type, typo correction, search by filters and sorting;
• catalog volume, its update rate, and requirements for result freshness;
• target response time per query and app behavior if search is unavailable;
• access rules: which fields are visible to different roles and what must not be indexed;
• current Elasticsearch configuration: indexes, analyzers for the app's languages, replicas;
• app release plan to which the work needs to be tied.

On the call, we go through this data and analyze exactly where relevance is lost: in text parsing, in the set of fields, in weights, or in caching on the app side.

Separately, we record how reindexing will proceed without stopping search and which scheme we roll back to if result quality drops.

We come back with a work plan: scope by stages, order of stages, control points, and acceptance criteria — for example, the share of queries where the needed product or document appears in the first three results. Describe the task in free form — we'll come back with an estimate and plan.