Caching layers
A cache is easy to describe and hard to justify. It is a copy of some data kept somewhere faster than the place the data lives. The copy is the whole point and the whole problem: from the moment it exists, the system holds two versions of the truth, and it has to decide what to do when they disagree.
Where a copy can live
The same request can be served from copies at several distances from the reader.
| Layer | Where the copy sits | Typical hit latency | Who invalidates it |
|---|---|---|---|
| Browser | On the reader's device | 0 ms | Headers you sent earlier |
| CDN | A shared edge near the reader | ~5 ms | Purge calls and time limits |
| Application | Memory inside your server | ~0.1 ms | Your code |
| Distributed | A cache service beside your servers | ~1 ms | Your code, across machines |
| Database | Buffer pool inside the database | ~0.05 ms | The database |
The layers closer to the reader are faster and harder to control. The layers closer to the data are slower and easier to keep correct. Most designs use more than one, and the difficulty is agreeing on what each one is allowed to be wrong about.
The question to ask first
Not "where should the cache go?" but "how stale may this value be, and who decides?" A profile picture that is a minute old is fine. An account balance that is a minute old is a support ticket. The tolerable staleness decides which layers are available to you.
Reads, writes, and the gap between them
Every cache strategy is a policy for the gap between a write reaching the source of truth and the copy catching up.
- Cache-aside keeps the application in charge: read the cache, fall through to the database on a miss, write the result back. Simple, and the gap is whatever your invalidation forgets.
- Write-through updates the cache and the database together. No gap on the path you control, at the cost of a slower write.
- Write-behind updates the cache now and the database later. Fast writes, and a window in which a crash loses data. This one needs a durability argument, not just a latency one.
Engineering note. Write down what a reader may observe during the gap, in one sentence, before choosing a strategy. If you cannot write the sentence, you do not yet know what the cache promises.
When not to add one
The shortener's lookup path already answers under its latency target from the database alone. A cache there would add a second copy, an invalidation rule, and a failure mode, in exchange for speed the brief never asked for. Add the layer when a measurement says the source cannot keep up, not when a diagram looks empty without it.
The next lessons take the layers one at a time: eviction policies, expiry, concurrency under load, and what happens when the cache itself disappears.
Continue with the complete track
Keep your progress and unlock the surrounding lessons, exercises, and complete learning path.
Unlock the complete track