What is a cache?
A cache is a small, very fast copy of data you already fetched once, kept close so you never repeat slow work for the same question. That is the entire idea — a sticky note next to the filing cabinet.
You already cache constantly. You remember your best friend's number instead of looking it up. Your browser keeps this page's logo on disk so the next page does not re-download it. Software caches are the same move: the first lookup is slow (ask the database, ~50ms), so you keep the answer somewhere fast (memory, ~1ms) for everyone who asks next.
Caches earn their keep on one condition: the same questions get asked again and again. If every question is brand new, a cache is just an extra place for answers to not be.
- cache hit
- — the answer was in the cache — fast path
- cache miss
- — it was not — do the slow work, then store the answer
- TTL (time to live)
- — how long a cached answer is trusted before it expires
Words to know
The database is drowning
SliceNow added the load balancer and five app servers — the web tier is fine now. But EVERY request still ends at the same place: the menu is read from the database on every single visit, and one database comfortably serves about 1,000 queries per second.
Lunch rush brings 8,000 menu reads per second. And here is the absurd part: the menu changed twice this week. The database is answering the same question eight thousand times a second, and the answer has not changed in days.
This shape — reads vastly outnumber writes, and a few items get most of the reads — is the cache's home turf. Put the menu in a cache: the first read is a miss (50ms, then stored), the next several million are hits (~1ms) that never touch the database at all.
Menu reads at lunch
8,000/sec
One database serves
~1,000/sec
Menu changes
twice a week
Quick check
Which of these workloads benefits MOST from a cache?
Hits, misses and TTL — one request, traced
Follow the value of one lookup, step by step. A customer opens Tony's menu. The app server asks the cache first: "menu:tonys?" — not there. That is a miss. The server does the slow work — reads the menu from the database (50ms) — answers the customer, and stores a copy in the cache with a TTL of 5 minutes.
Nine seconds later another customer opens Tony's menu. Cache first: "menu:tonys?" — found! A hit. Answered in 1ms; the database never hears about it. For the next 5 minutes, every request for Tony's menu is a 1ms hit.
At the 5-minute mark the entry expires (that is all TTL means: "trust this answer for this long"). The next request misses, re-reads the database — picking up any changes Tony made — and re-fills the cache. The rhythm is: miss → slow work → remember → hits until expiry → repeat.
Where caches live
The same idea appears at every layer — only the distance changes.
| Layer | What it remembers | Typical speed | Example |
|---|---|---|---|
| Browser / app | Images, styles, recent API answers | instant (on device) | Logo loads once, shown everywhere |
| CDN (next lesson) | Static files, per city | ~10-30 ms | Menu photos served from near the user |
| Application cache | Hot data shared by all app servers | ~1 ms | Redis holding menu:tonys |
| Inside the database | Recently-used rows and indexes | ~1-10 ms | Repeated query answered from RAM |
Common trap — The price you pay: staleness
From the moment data is cached until it expires or is evicted, the cache may be LYING — Tony raised the pizza price, but customers still see the old one for up to 5 minutes. Every cache decision is really this trade: how much staleness can this data tolerate? Menus: minutes are fine. Account balances: not even seconds.
Quick check
You cache the menu with a 24-hour TTL instead of 5 minutes. What did you just trade?
Match them up
Match each term to its plain meaning.
0/5 matched — tap a term on the left.
Build it yourself
Save SliceNow's database from the 8,000 menu reads per second. Build the full read path — and put the cache where the app servers can check it BEFORE falling back to the database. One palette piece cures a pain you do not have — leave it off.
Tip — When NOT to cache
Skip the cache when data is written as often as it is read (driver GPS pings), when every request is unique (PDF receipts), or when staleness is unacceptable (payment balances, stock levels during a flash sale). A cache that is always wrong or always missing is pure overhead — being able to say this out loud is an interview superpower.
Apply it in an interview
"Redirects must feel instant and reads dwarf writes" — the URL-shortener problem is a caching story at heart. Go design it like an interview, with the AI interviewer probing your choices.