Databases
Almost every serious application is, underneath, a database with a user interface bolted on. Get the data layer right and everything above it gets simpler.
A table is just a set of rows, but the relational model's power is that you say what you want, not how to get it — and a query optimizer, every time, works out the how.
Master that and you stop writing loops to do what one statement can. Describe the result, and the engine chooses the joins, the order, and the indexes for you.
Indexes are the reason it works at scale. A B-tree turns a full scan of a billion rows into a handful of pointer-follows — the same idea that makes a lookup in a dictionary instant.
Underneath, indexes, query planners, and storage engines race to answer those queries quickly — the difference between a query that returns instantly and one that times out.
Joins are where the model earns its name: keys stitch separate relations back together, so the same fact lives in one place and every query that needs it finds it there.
And when many users hit the same data at once, transactions keep it correct. Concurrency and recovery are what let you trust the number in the account is right — even when everything fails at the worst possible moment.
It all has to survive failure. Write-ahead logs, isolation levels, and two-phase commit are the unglamorous machinery that lets a bank trust its own numbers when the power dies mid-transaction.