Elasticsearch

Elasticsearch is a distributed search and analytics engine built on an inverted index. When a feature is "let users search text and get the best matches ranked first" — product search, log search, "find posts about X" — a relational LIKE '%term%' falls over (it can't rank, can't handle typos, and scans the table). Elasticsearch is the specialised tool for that job.

Why it's fast at search

A normal index maps a row to its contents. An inverted index flips that: it maps each word to the list of documents containing it. So "find documents with 'networking'" is a direct lookup of a precomputed list, not a scan. On top of that, Elasticsearch scores results by relevance (how well a document matches), so the best matches come first — and it handles stemming (run matches running), typo tolerance, and synonyms.

What it gives you beyond search

• Full-text, ranked search across many fields with per-field weighting.
• Filters + facets — "jackets, under $100, in stock, size M," plus the counts for each facet.
• Aggregations — group-bys and stats over huge datasets, which makes it a common log/metrics analytics backend (the "E" in the ELK stack).
• Geo search — "within 5km of here."

The golden rule: it's a secondary index

Elasticsearch is not your source of truth. It's a copy, optimised for search, that you feed from your primary database. Writes go to Postgres (or wherever); a pipeline then indexes the searchable fields into Elasticsearch — synchronously, via a queue, or via change-data-capture.

[ Postgres (truth) ] ──index pipeline──► [ Elasticsearch (search copy) ]
writes here                              queries here

This keeps your transactional store simple and your search store fast, and it means Elasticsearch can be rebuilt from the source if it's ever lost or its mapping changes.

What to watch

• Eventual consistency. The index lags the source by the pipeline's delay. A product just added may not appear in search for a moment — usually fine for search, never acceptable for a balance.
• Mappings are sticky. The field types/analyzers are set when the index is created; changing them often means reindexing. Design the mapping with your queries in mind.
• It's heavyweight. A cluster is real operational work. For small catalogues, Postgres full-text search (a GIN index on a tsvector) is plenty — only reach for Elasticsearch when search is a core feature at scale.

What to say in an interview

Use it as a search index fed from the source of truth, and know the cheaper alternative:

"Search is a core feature, so I'd index the searchable product fields into Elasticsearch and query it for ranked, filtered search. Postgres stays the source of truth; I'd keep the index fresh with change-data-capture off the products table. If the catalogue were small I'd skip the cluster and use a Postgres full-text GIN index instead."

Next up: Kafka — the log that absorbs firehoses and decouples producers from consumers.