Module 21 / Key technologies

Module 21 · lesson 2 of 7 · Read 8 min

Elasticsearch

Inverted indexes, shards, relevance, and keeping it in sync.

What you'll learn

  1. What it's best at
  2. The inverted index
  3. Shards, replicas and how a search runs
  4. A real query
  5. Keeping it in sync
  6. Limits and failure modes
  7. When not to use it

A Tiffin customer types "chiken biryani" into the search box. They expect to see biryani places nearby, open right now, best matches first, in under 200 milliseconds, despite the typo. A LIKE '%biryani%' query on Postgres can't do this well: it can't use a normal index, it doesn't rank, and it doesn't forgive spelling.

Elasticsearch is built for exactly this. It's a distributed search engine on top of the Lucene library. Module 9 introduced the idea of a separate search index fed from the main database. This lesson looks at how Elasticsearch works inside, so you can size it, feed it and know where it breaks. (OpenSearch, the fork AWS started in 2021 and now run by the Linux Foundation, works the same way for everything here.)

What it's best at

  • Full-text search: words, phrases, typos, synonyms, ranked by relevance.
  • Filtering plus search: "biryani, open now, within 5 km, rating above 4".
  • Aggregations: counts and buckets, like "how many results per cuisine" for the filter sidebar.
  • Log and event search: the "E" in the ELK stack. Huge volumes of append-only documents, searched by time range and text.

It is a secondary store. Your orders and menus live in a real database; Elasticsearch holds a searchable copy.