In this chapter
We'll meet index lifecycle, mapping, schema evolution, and near-real-time search consistency, plus search performance and Elasticsearch's own double life powering both product search and observability.
The Problem in Real Life
The cluster answers "how does search spread across machines." Mike asks the question that comes right after: GreenMart's catalog changes every day — new products, updated prices, sellers editing listings. Does the index just... keep up?
It does, but not instantly, and not by accident. Sarah walks Mike through what actually happens between a seller hitting save and that change showing up in search.
If a seller updates a price right now, how fast does search actually know?
Mike
Staying Current, Correctly Structured, and Fast
Mapping and schema evolution, again
Elasticsearch's own word for a schema — and the same evolving-shape problem every earlier database in this course has had.
Near-real-time, not instant
A small, deliberate refresh interval before a new write becomes searchable — the same eventual-consistency trade-off, in a new place.
Index Lifecycle, Mapping & Search Performance
Two real, separate questions hide inside Mike's one. How does an index stay correctly structured as GreenMart's catalog's own shape changes over time? And once it's genuinely large and constantly being written to, what keeps it fast?
- On staying current and correctly structured. An index lifecycle describes how an index isn't static forever — data ages out, gets reindexed, or rolls over into new indexes over time (a common pattern: a fresh index every day for time-stamped data). Mapping is Elasticsearch's own word for a schema: declaring, per field, how it should actually be analyzed and indexed — a product's title tokenized for full-text search, a product's exact SKU code left as an untouched, exact-match-only value. Schema evolution shows up here too, the same real problem every earlier database in this course has had its own version of: GreenMart's catalog's shape changes over time, and a mapping has to be able to change with it.
- On the gap between a write and a searchable result. Near-real-time search is an honest, specific detail: a new or updated document doesn't become searchable the literal instant it's written — there's a small, deliberate refresh interval (often around one second) before it's queryable. Search consistency describes that same brief window: a query might not yet reflect the very latest write, the same eventual-consistency-flavored trade-off this course has met before, in a new place.
- On running this at real, sustained scale. Search performance depends directly on shard count, replica count, and how complex the actual queries running against the cluster are — the same real, learnable trade-offs this course has already built intuition for with every earlier database's own scaling story. Logs and observability is a genuinely interesting detail worth naming on its own: the exact same technology built for product search is also one of the most common tools used to search and analyze application logs and monitoring data — Elasticsearch's role in most companies' observability stack isn't a coincidence, it's the same full-text search and aggregation machinery, pointed at a different kind of document.
Put together: a catalog isn't a fixed shape indexed once. It's a living structure, with its own lifecycle, its own brief and honest delay between a write and a searchable result, and its own real performance trade-offs — and the same machinery, pointed at a different kind of document, is why the search bar and the ops team's log dashboard so often run on exactly the same technology.
Key Takeaway
Search isn't a snapshot taken once — it's a living index, constantly reindexing, briefly behind the very latest write, and tuned the same way every other database in this course has been: by understanding exactly what's being traded away for speed.
Why This Matters
This closes the loop this Act's very first chapter opened with: GreenMart needed search to answer a genuinely different question than a database query, and this chapter shows that answer has to keep staying current, correctly structured, and fast, not just work once on day one.
GreenMart now understands what a search index looks like at real scale — near-real-time, evolving alongside the catalog it indexes, tuned for real performance. The checkpoint ahead asks Sarah — or you — to build GreenMart's actual product search from scratch, with every one of this Act's lessons made on purpose.