§01What a cache does
A cache stores the result of recent work so you can return it again without redoing the computation or re-fetching from the database. It's a memory of "what did we just answer?".
- Cache hit = answer is in cache, return immediately. Cheap.
- Cache miss = not in cache, fall through to the database, then store the result. Expensive (this time).
- Hit rate = % of requests served from cache. Higher = better.
§02Read patterns
⚑ NOTE
Cache-aside (most common)
Server checks the cache first. On miss, it queries the DB and writes the result back into the cache. Next request for the same key hits.
⚑ NOTE
Read-through
Server always asks the cache; the cache itself fetches from the DB on miss. The server doesn't know about the DB.
§03Write patterns
- Write-through: write to cache and DB at the same time. Strong consistency, slower writes.
- Write-behind: write to cache now, DB later (async). Fast writes, risk of loss on crash.
- Write-around: write only to DB, let the cache fill on next read. Avoids cache pollution from one-shot writes.
§04When caching helps
Caches shine when the same answer is requested many times (read-heavy, hot keys). They don't help when every request is unique, and they can hurt if the cache hit rate is low (you pay for the cache lookup AND the DB read).
⚑ CHEATSHEET · QUICK REFERENCE
- Cache reads; the DB stays the source of truth.
- On the canvas, set the edge's cache hit rate to model your workload's locality.
- If the cache barely helps, your traffic isn't read-heavy — try a different lever.
▸ THE EXERCISE
Database reads are expensive. Put a cache between your servers and the database. Tune the hit rate on the cache edge.