Document versus Term Partitioning

In one line: this is the chapter's central trade-off, and the winning answer looks wrong at first — document partitioning sends every query to every node, which sounds strictly worse than the alternative. It is not.

The two schemes

Scheme	What is split	A node holds
Document partitioning	Documents are split into subsets. Each node indexes its assigned subset	A complete index over a slice of the corpus — every term, some documents
Term partitioning	The dictionary of terms is split. A single node handles a specific set of terms (e.g. all terms starting with 'search')	A partial index over the whole corpus — some terms, every document

Partition by DOCUMENTS                    Partition by TERMS
----------------------                    ------------------
Node 1: docs 1-1000                       Node 1: elasticsearch, distributed
        all terms in them                         across ALL documents

Node 2: docs 1001-2000                    Node 2: restful, engine
        all terms in them                         across ALL documents

Node 3: docs 2001-3000                    Node 3: analytics, stack
        all terms in them                         across ALL documents

Query hits ALL nodes.                     Query hits only the nodes
Each returns local top-K.                 holding its terms.
Merge centrally.                          Merge requires shipping
                                          posting lists between nodes.

Term partitioning looks more efficient — touch fewer shards — and loses on the operation that matters. A two-word query needs an intersection, and if the two posting lists live on different machines one of them has to travel. For a common term that list is enormous.

The trade-off

Term partitioning sends queries only to nodes handling specific terms. While this increases concurrency, multi-word queries require expensive data transfer between nodes to merge results.

Document partitioning sends every query to all nodes, and results are merged centrally. This requires less inter-node communication. We will use document partitioning in our design.

Term partitioning fails because intersection has to happen somewhere

Term partitioning looks better on paper: a two-word query touches two nodes instead of all N. Less work, more concurrency, obviously superior.

The problem is what those two nodes have to exchange. Lesson 4 established that a multi-term query is a posting-list intersection. Under term partitioning, search lives on node A and engine on node B — and neither can compute the intersection alone.

So one of them must ship its posting list to the other. Lesson 4 also noted a common term can match millions of documents, so that list is megabytes of document IDs crossing the network, per query.

Under document partitioning, both terms are on every node, so every node computes its own intersection locally and returns only its top-K — a handful of results. The merger combines a few small lists instead of a few enormous ones.

The framing that makes it click: term partitioning moves data at query time; document partitioning moves only answers. Intersection is where the data volume is, so you want it to happen where the data already is.

'Sends every query to all nodes' sounds wasteful and isn't

The obvious objection: fanning out to 100 nodes for one query seems like 100x the work.

It is not, because each node's work is 1/100th the size. The total work is the same; it is done in parallel, so latency is what improves. That is precisely Lesson 2's "low latency regardless of data volume" — grow the corpus, add nodes, and each node's slice stays constant.

There is a real cost, and it is worth naming: the query's latency is set by the slowest node, not the average. With 100 nodes, you are exposed to the tail of 100 latency distributions on every query — the classic tail-at-scale problem the non-functional characteristics material described.

Mitigations exist — hedged requests to a replica, or returning results once 99 of 100 nodes have answered — and mentioning that shows you know fan-out is not free even though it is right.

Both schemes have a natural home — this is not universal

Document partitioning wins here, for a specific reason: queries are multi-term and results are top-K by relevance.

Term partitioning is better when queries are single-term or when you need the complete posting list for a term rather than a ranked few — some analytics workloads, or systems doing set operations over full result sets. There, sending the query to one node that holds everything about that term is exactly right.

The general rule: partition so that a typical query can be answered locally. Document partitioning does that for multi-term ranked search; term partitioning does not. Same principle as object storage partitioning by full path so a listing hits one partition — you look at the dominant query and partition to keep it local.

Document partitioning breaks global statistics — the honest cost

Here is what document partitioning genuinely gives up, and few candidates mention it.

Relevance ranking usually needs corpus-wide statistics — most famously inverse document frequency, which requires knowing how many documents in total contain a term, so rare terms count for more than common ones.

Under document partitioning, no node knows the global count. Each sees only its own slice. So each node's "top-K by relevance" is computed against local statistics, and a term that is rare globally but common in one partition gets scored inconsistently across nodes.

The standard fixes: periodically broadcast global term statistics to every node, or accept the approximation on the grounds that with enough documents per partition, local frequencies approximate global ones well.

It is a real, subtle cost — and naming it demonstrates you understand ranking rather than only retrieval.

Key takeaway

Document partitioning: each node holds a complete index over a slice of the corpus, every query fans out to all nodes, each returns local top-K. Term partitioning: each node holds some terms across the whole corpus, so multi-term queries must ship posting lists between nodes. Intersection is where the data volume is, so put it where the data already is — move answers, not data. The costs are tail latency across the fan-out and loss of global term statistics.

Interview signal by level

Level	What a strong answer sounds like
L4	"Split the documents across nodes so each one indexes part of the data."
L5	Contrasts the two: "term partitioning only touches the nodes holding the query's terms, but a multi-word query then needs posting lists shipped between nodes — document partitioning fans out but each node returns just its top results."
Staff+	Frames it as data movement and names the costs: "the intersection has to happen somewhere, and it's where the volume is — term partitioning moves millions of document IDs across the network per query, document partitioning moves only top-K answers. The costs are real though: query latency is set by the slowest of N nodes, so we're exposed to the tail on every request and want hedged requests. And no node knows global document frequency, so IDF-style ranking needs broadcast statistics or an approximation."

Next: running indexing and search across the cluster.