Core Building Blocks

Elasticsearch

Harold

Harold

— 2 min read
Share
Elasticsearch 
Elasticsearch is used when a normal database is not good enough for search.
In interviews, use it for full-text search, filtering, ranking, autocomplete, and geo search.

What Elasticsearch does

Elasticsearch is a search engine.

It helps you search through large amounts of text and structured data quickly.

Examples:

  • search restaurants by keyword,
  • search products by name and category,
  • search posts by text,
  • search nearby businesses,
  • autocomplete search suggestions,
  • filter by rating, price, location, or tags.

A normal database can handle simple lookups well.

SELECT * FROM users WHERE id = ?

But it is not great for large full-text search.

WHERE title LIKE '%sushi%'

At large scale, this can become slow.

The key idea: inverted index

Elasticsearch uses an inverted index.

Think of a book index.

Instead of reading every page to find a word, you look at the index and see where the word appears.

Example:

"sushi" → document 12, document 91, document 204
"pizza" → document 5, document 44, document 300
"ramen" → document 18, document 91

This makes keyword search much faster.

When to use Elasticsearch

Good interview signals:

  • full-text search,
  • fuzzy matching,
  • autocomplete,
  • ranking by relevance,
  • many filters,
  • geo-distance search,
  • SQL LIKE is too slow,
  • search results do not need to be strongly consistent.

Examples:

  • Yelp search,
  • Amazon product search,
  • Twitter search,
  • job search,
  • Google Maps business search,
  • document search.

When not to use Elasticsearch

Do not use Elasticsearch for everything.

Avoid it when:

  • you only need lookup by id,
  • you need strong consistency,
  • the data is small,
  • the query is simple,
  • the database index is enough,
  • Elasticsearch would become the source of truth.

A good sentence:

I would use Elasticsearch as a secondary search index, not as the primary database.

Elasticsearch is not the source of truth

Usually, the primary database remains the source of truth.

Elasticsearch is updated from the database.

Common flow:

Write to database
→ publish event to message queue
→ sync worker updates Elasticsearch

Search reads from Elasticsearch.

Detail pages may read from the database.

Search query → Elasticsearch
Item detail → Database or Cache

Eventual consistency

Elasticsearch is often eventually consistent.

That means a new record may not appear in search immediately.

For most search systems, this is acceptable.

Example:

If a new restaurant takes a few seconds to appear in search, that is usually fine.

But for money, inventory, or booking state, this is not acceptable.

Common mistakes

  • Using Elasticsearch as the main database.
  • Forgetting that search may be eventually consistent.
  • Using Elasticsearch for simple primary-key lookup.
  • Not explaining how data gets synced.
  • Ignoring ranking and filtering requirements.

Final takeaway

Elasticsearch is useful when search is a core feature.

A strong answer is:

I would keep the primary database as the source of truth and use Elasticsearch as a secondary search index. Data is synced asynchronously through a queue, so search is eventually consistent, which is acceptable for this use case.

Read more