Elasticsearch
maang.io System Design Series
Elasticsearch takes Lucene and distributes it: an index splits into shards (each a Lucene index) with replicas, spread across nodes. It adds near-real-time indexing (buffer → refresh → segment, with a translog for durability), scatter-gather query then fetch, and a rich query DSL and aggregations. It's the default answer for full-text search and log analytics at scale.
This deep dive comes in four parts:
- Foundations & Core Concepts — indices, shards/replicas, and document routing.
- Internals — the near-real-time model, translog, refresh/flush, and segment merges, with worked numbers.
- Advanced Internals — node roles, the query/fetch phases, mappings, and doc values for aggregations.
- Interview — Staff/Principal Q&A: sizing shards, and when not to use it as a primary store.
Elasticsearch — Part 3: Distribution, Routing & the Read Path
maang.io System Design Series
What is this?
We've toured one library branch — its inverted index, its sealed booklets, its daybook. But the real library has dozens of branches and a head librarian at a central desk. When you ask "who mentions distributed consensus?", the head librarian doesn't know the answer — no single branch does. So they fan your question out to every branch, each branch searches its own catalog and sends back a short list of its best hits, the head librarian merges those short lists into one ranked answer, and only then fetches the actual books for the top results. That two-round dance — ask everyone for candidates, then fetch the winners — is the single most important distributed idea in Elasticsearch.
And there's the mirror-image question for writes: when a new book arrives at the front desk, which branch should own it? You can't put it wherever — searches and updates need to find it deterministically. The answer is a hash. Let's build the whole distributed layer: how documents are routed to shards, who does what in the cluster, how a search scatters and gathers, and how it all survives a branch burning down.
The one-line idea: A document is pinned to one primary shard by hashing its routing key, so writes and get-by-id go straight to the right shard; but a search can't know which shards match, so it scatters to one copy of every shard and gathers the results in two phases — query (collect ranked doc ids) then fetch (retrieve the winning documents). Everything else — node roles, replication, recovery — exists to make that scatter-gather fast and fault-tolerant.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson