Database Indexing
Why reads get 1000x faster and writes pay a small tax.
An index is a sorted lookup structure the database keeps next to a table so it can find rows without reading the whole table. Most indexes are B-trees — balanced trees that reach any row in a handful of hops.
The animation opens with the pain: a stack of one million unsorted cards, scanned one by one while a timer spins. That is a full table scan — on a big table, the difference between 30 seconds and 5 milliseconds. Then the same query runs against a B-tree: three highlighted hops, straight to the card. Because the tree is sorted, it also answers range queries ("everything between March and May") the same fast way.
Then watch the cost appear: an insert lands in the table, and a ripple runs through the tree as the index updates itself too. Every index you add makes every write a little more expensive and takes storage — which is why you index the columns your queries filter on, not everything.
In interviews, when you draw a table, the follow-up is "how does the read for your main endpoint stay fast?" The expected answer names the exact index: "index on short_code," or "compound index on (creator_id, created_at) for pagination."