Hire Elasticsearch Engineers

Elasticsearch is easy to stand up and easy to get quietly wrong, because the defaults will accept almost anything. Documents index, queries return, and nobody notices that the analyser is splitting part numbers on hyphens until a customer searches for one and gets nothing.

Mapping is the decision you cannot easily unmake

Mapping is the decision that matters most and the hardest to change afterwards. Text or keyword, which analyser, whether a field needs both — these determine what is searchable and how, and changing them means a reindex. Getting it wrong is not fatal, but it is expensive at volume and it tends to be discovered by a user rather than a test.

A text field is analysed into terms and is what you search; a keyword field is stored whole and is what you filter, sort and aggregate on. Most mapping arguments come down to somebody having picked one when the field needed both, and dynamic mapping quietly picking for them.

Relevance is measured, or it is superstition

Relevance is the second, and it is where most projects stop too early. “It returns results” is not the bar. The bar is whether the thing the person wanted is in the first three, and answering that requires a set of real queries with known good answers, checked after every change to boosting or analysis. Without that, relevance tuning is superstition — someone adds a boost, it feels better, and something else silently gets worse.

A workable judgement set does not need to be large:

• Fifty to two hundred real queries taken from the logs, weighted towards the frequent ones
• A known good result for each, agreed with somebody who understands the domain
• A score that is recomputed on every change, not on request
• The deliberately awkward cases — misspellings, part numbers, synonyms nobody standardised

Shards, and the two ways to get them wrong

Shard strategy is the third. The common failure is many small indices with five shards each, inherited from an old default, producing thousands of shards and a cluster that spends its time on overhead. The opposite failure — one enormous index that cannot be reindexed inside a maintenance window — is rarer and worse.

The useful habit is to size a shard against how it will be reindexed and recovered rather than against how it will be queried, because query performance degrades gradually and recovery time does not.

Search and logs are two different products

An observability cluster and a product search cluster look alike and behave nothing alike. Logs are write-heavy, time-partitioned, queried by a handful of people and safe to age out. Product search is read-heavy, latency-sensitive, and every query has a user waiting on it.

Running both on one cluster is the classic economy that stops being one. A log ingest spike becomes a slow search page, and the team that owns the search experience has no control over the thing that degraded it.

Reindexing without taking the search down

Because mappings change, reindexing has to be routine rather than exceptional, and the mechanism for that is an alias. Applications read and write through an alias, a new index is built beside the old one, and the alias is switched atomically once the new index is verified.

Teams that address indices directly discover this the first time a mapping has to change under load, and the migration then involves a maintenance window and a negotiation.

When you do not need Elasticsearch

If the data fits comfortably in the primary database and the queries are filters rather than searches, full-text support in Postgres or the equivalent is less to run and one fewer system to keep consistent.

If the requirement is analytics over historical data, a warehouse will answer it better and more cheaply than aggregations over an index sized for search latency.

Elasticsearch earns its place where users type words rather than choose filters, where relevance ordering genuinely matters to the outcome, or where the volume and shape of log and event data have outgrown grep and a database.