19. Search and Inverted Indexes
19.7 Where does Elasticsearch fit in the big picture?
In the library: A large library doesn't keep one cabinet. It has a catalogue department: cabinets in several rooms, copies of each in case one burns, and staff who know which cabinet holds which books.
In the system: Elasticsearch (and its fork OpenSearch) is a distributed search engine built on Apache Lucene, the library that does the inverted index, analyzers and scoring. Elasticsearch adds the distribution:
| Concept | What it means |
|---|---|
| Document | A JSON object, like one book |
| Index | A collection of documents, like the catalogue |
| Shard | A slice of an index; each shard is a full Lucene index |
| Replica | A copy of a shard, for failover and more read capacity |
| Mapping | The schema: which fields exist and which analyzer each uses |
| Refresh | Makes recent writes searchable (about once a second by default) |
Where it sits in a typical design:
App ──write──▶ Database ──CDC/outbox──▶ Indexer ──▶ Elasticsearch
App ──search──────────────────────────────────────▶ Elasticsearch ──▶ IDs ──▶ App fetches details
What it's good at: full-text search, ranking, filters ("in stock, under ₹500"), facets (counts per category), autocomplete, geo queries (Chapter 18), and log analytics.
What it isn't: your primary database. It doesn't give you transactions across documents, and it's built to be rebuilt from the source of truth. Keep the database as the truth and treat the search cluster as a fast, rebuildable copy.
Memory code: "Lucene does the cards; Elasticsearch runs the department."