In this chapter
We'll meet search indexes at scale — shards, replicas, and distributed search coordination — and the real production technologies (Elasticsearch, OpenSearch) built around exactly this architecture.
The Problem in Real Life
GreenMart's catalog search works beautifully today — a few thousand products, one search index, instant results. Sarah does the math on where the business is headed: national delivery, dozens of new sellers a week, a catalog that could be ten times this size within a year, all being searched constantly.
One search index, on one machine, has a ceiling. Sarah wants to know where it is, and what happens once GreenMart hits it.
This works today. I want to know what breaks first when it doesn't.
Sarah
One Search Index vs. A Search Cluster
Shards split an index across machines
The same partitioning idea as Cassandra and DynamoDB, this Act's own version — smaller, independently searchable pieces.
Distributed search means merging results
Every shard returns its own best matches; assembling one correctly-ranked final answer is genuinely harder than a single-machine search.
Shards, Replicas & Distributed Search
How does a search index actually spread across more than one machine, and stay correct while doing it? The same pattern this course keeps returning to, with search's own real twist.
- On spreading across machines — how does a search index scale? A search index is the whole searchable structure for a dataset — GreenMart's product catalog, as one index. Past a certain size, one index gets split into shards — smaller pieces, each independently searchable, spread across multiple machines, the same underlying idea as Cassandra's partitions or DynamoDB's partition keys, this Act's own version of a lesson this course keeps re-teaching in a new place. Replicas are real copies of each shard, kept for redundancy and to let more than one machine answer read queries at once.
- On coordinating the search itself. Distributed search is the coordination this requires: a query gets sent to every relevant shard, each shard returns its own best matches, and the results get merged and re-ranked into one final, correctly-ordered list — a genuinely harder problem than searching a single machine, since "the top 10 results" now has to be assembled from several machines' own top candidates. Elasticsearch and OpenSearch are the real, dominant production technologies built around exactly this architecture — a cluster of nodes, each holding shards and replicas of one or more indexes.
None of this changes anything a reader has already built in this Act — the tokenization, relevance, and faceted search from earlier chapters all still apply the same way inside a single shard. What a real search cluster adds is the machinery to keep doing all of that correctly once one machine, and one index, genuinely isn't enough anymore. The next chapter picks up from here: how that cluster stays current and fast as GreenMart's catalog keeps changing underneath it.
Key Takeaway
A search index scales the same way this course's other databases have already scaled — split into shards, replicated for safety, coordinated across machines — but search adds its own real twist: merging several machines' independent "best guesses" back into one correctly-ranked answer is a harder coordination problem than a plain lookup ever was.
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 even that harder question has to keep working correctly once it's running across a real cluster, not one convenient machine.
GreenMart now understands what a search index looks like at real scale — sharded, replicated, coordinated across machines. The next chapter covers what it takes to keep that cluster fast and current as the catalog itself keeps changing.