The Back of the Book, at Internet Scale
Open any textbook and flip to the back. There's an index, an alphabetical list of terms with page numbers. "Caching: 45, 67, 112." ": 23, 89." Instead of reading every page to find where "caching" is discussed, you look it up in the index and go directly to the right pages.
An inverted index is the exact same idea, applied to a database of documents.
Without an inverted index, searching for the word "" across 10 million documents means scanning every single document, reading every word, to find matches. That's a full scan, and it's catastrophically slow.
With an inverted index, you look up "kubernetes" in the index and instantly get a list of every document containing that word, along with metadata about where in each document it appears and how often.
This is the foundational data structure behind , Solr, Lucene, Google Search, and every full-text search system ever built. It's not optional or clever, it's essential. Without it, search at scale simply doesn't work.
How an Inverted Index Works
Given three documents:
Doc 1: "The cat sat on the mat"
Doc 2: "The dog sat on the log"
Doc 3: "The cat chased the dog"
A forward index maps documents to their words:
Doc 1 → [the, cat, sat, on, the, mat]
Doc 2 → [the, dog, sat, on, the, log]
Doc 3 → [the, cat, chased, the, dog]
An inverted index flips this, mapping words to their documents:
the → [Doc 1, Doc 2, Doc 3]
cat → [Doc 1, Doc 3]
sat → [Doc 1, Doc 2]
on → [Doc 1, Doc 2]
mat → [Doc 1]
dog → [Doc 2, Doc 3]
log → [Doc 2]
chased → [Doc 3]
Now searching for "cat" is a single lookup: return Doc 1 and Doc 3. Searching for "cat AND dog" means finding the intersection of [Doc 1, Doc 3] and [Doc 2, Doc 3], which is [Doc 3].
The "inverted" refers to the direction of the mapping. A forward index maps documents to words. An inverted index maps words to documents. The inversion is what makes search fast, you start from the query term and immediately find relevant documents.
The example above uses three toy documents. This is the same structure built over the real corpus you are reading right now.
On the left is the term dictionary, on the right the posting list. Look a term up once and get the list of documents that contain it. The chains are cut short in the drawing because database really does appear in 560 lessons and there is no way to draw 560 cells.
An AND query is a merge, not a search. To answer cache AND eviction the engine walks both sorted lists together, 287 postings in total, and hands back 24 lessons. It never opens a lesson. A grep across the corpus would read all 1,064,624 words to answer the same question.
Now read the percentage column, which is the part most people skip. database appears in 67 percent of lessons. As a filter it is nearly worthless: it eliminates a third of the corpus and costs 560 postings to walk. eviction appears in 3 percent. Starting the merge from the shorter list is what makes the query cheap, and it is why real engines sort query terms by document frequency before running them.