Start from zero: what a cache actually is
A cache is a fast nearby copy of expensive-to-get data. This is the from-zero map and the eight words the rest of the caching track assumes you already know.
Your app is slow. A user clicks “Load profile” and waits two seconds while your server queries the database, joins five tables, and serialises a JSON blob — every single time, for every single user, even though the data barely changes. Now imagine your server could answer in two milliseconds instead, by keeping a ready-made copy of that answer close by. That is a cache. It is the oldest trick in computing — CPUs have been doing it since the 1960s — and yet it is the source of one of the most famous quips in all of software engineering: “There are only two hard things in computer science: cache invalidation and naming things.” This lesson is the map of those two hard things before you climb into the details.
The one problem a cache solves
Every useful program eventually hits the same wall: getting data is slow. Maybe it requires a round-trip to a database. Maybe it needs a network call to a third-party API. Maybe it demands a CPU-intensive calculation. Whatever the cause, the cost is real — and if many users need the same data, you pay that cost over and over for the same result. A cache breaks the repetition. Instead of going back to the original source each time, you store a copy somewhere faster and closer to the reader. When you profile a slow endpoint and find the same database row fetched hundreds of times per second, that is the wall a cache is built to break. The next request finds that copy and finishes before the expensive journey even begins.
Everything else in this track is a refinement of that single idea: keep a fast copy nearby, but keep it honest.
The eight words the rest of the track assumes
You could dive straight into Redis eviction policies or CDN cache-control headers — but every one of those topics will use these eight words without pausing to explain them. Learn them once here and the rest of the track will feel like recognition, not mystery.
The senior lessons that follow drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Cache | A fast nearby copy of data that is expensive to fetch from its original source. | So repeated reads pay the high cost once instead of every time. |
| Cache hit | The moment a request finds the data already in the cache. | The fast path — no trip to the origin needed, answer returned immediately. |
| Cache miss | The moment a request finds nothing useful in the cache. | Triggers the slow path — fetch from origin, store the result, serve the copy. |
| TTL (time-to-live) | A countdown attached to each cached entry; when it hits zero the entry expires. | So stale data does not live forever — the cache eventually refreshes itself. |
| Eviction | Removing an entry from the cache before its TTL — usually because space runs out. | So the cache stays within its memory budget by discarding the least-useful entries first. |
| Staleness | The state of a cached copy that no longer matches the origin’s current value. | Understanding staleness is what separates a cache that helps from one that misleads. |
| Cache key | The identifier used to store and look up an entry — often the URL, query, or user ID. | So the cache can tell apart “profile for user 42” from “profile for user 99.” |
| Origin (source of truth) | The authoritative source the cache is a copy of — usually a database or upstream API. | So there is always a definitive place to fetch fresh data when the cache cannot help. |
| Invalidation | Deliberately removing or marking stale a cached entry when the origin data changes. | So users do not read outdated data after a write — the hardest problem caching poses. |
How they fit together
Read in order, the words tell one story: when a request arrives, check the cache by its cache key. If there is a cache hit, return the copy immediately — fast path done. If there is a cache miss, fetch the data from the origin, store it in the cache under the same key with a TTL, and return it to the caller. The next request for the same key is a hit. When the TTL expires the entry becomes stale and is treated as a miss again. If memory fills up, eviction removes the entries the cache deems least valuable. And whenever the origin’s data changes, invalidation removes the old copy so the next read pulls a fresh one. That single paragraph is the entire track in miniature — every later unit zooms into one of those steps.
▸Why this works
Why not skip the cache and always read from the origin? Because the origin is slow and often expensive. A database query that takes 50 ms sounds fine until 1,000 users ask the same question per second — now you need 1,000 database queries per second. A well-placed cache turns that into one database query per TTL and 999 instant hits. The cost is complexity: you now have two sources of truth and you must keep them in sync. That synchronisation problem — invalidation — is why caching is famous for being hard.
You do not need to memorise this
Two honest notes before the climb. First: nobody holds all of this at once on day one — you will meet each word again, in depth, in its own unit, and it will click then. This page is a coat-hook to hang the details on, not a test. Second: caches exist at every layer of a system — from the CPU’s L1 cache a few nanoseconds away to a CDN edge node a few milliseconds away — and the vocabulary above applies to all of them. The senior track walks through every layer. Start here, and each layer will feel familiar when it arrives.
A user requests a product page. The cache has an entry for it but the TTL expired ten seconds ago. What happens?
Order the lifecycle of a cache miss turning into a future hit:
- 1 Request arrives — check the cache by cache key, find nothing (miss)
- 2 Fetch fresh data from the origin
- 3 Store the result in the cache under the same key with a TTL
- 4 Return the data to the caller; next identical request is a hit
- 01In one breath: what is a cache, and what is the core trade-off it makes?
- 02Walk through what happens on a cache miss, naming every piece.
A cache is one idea with a lot of machinery hung off it: keep a fast nearby copy of expensive-to-get data so repeated reads are cheap. Every request checks the cache by its key first — a hit returns immediately, a miss fetches from the origin and repopulates the cache with a TTL. When the TTL expires the entry is stale and treated as a miss again; when memory runs out, eviction discards the least-useful entries to make room. The hard part is invalidation: when the origin changes, stale copies must be removed or updated so readers stay accurate. You will meet each of these words again in depth — this is just the map. Now when you see a slow endpoint, your first instinct should be to ask: is there a copy closer to the reader, and if not, what would it cost to add one?
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.