Topic 10.1
Why Cache?
In one line
Latency and load: the same data read 1000x a second shouldn't hit the DB 1000x.
Think of it like this
Keeping a jug of cold water in the fridge instead of walking to the well every time you're thirsty. The well (database) always has the truth, but the fridge (cache) gets you the same water much faster.
Key ideas
- 01
Serving from memory is ~100x faster than a DB hit (0.1ms vs 5ms read) and unloads the DB.
- 02
Where caches live: browser, CDN edge, reverse proxy, app instance, Redis cluster, DB buffer pool.
- 03
Cache at the layer closest to the user that still satisfies freshness → lowest latency wins.
- 04
The read:write ratio decides: 10:1+ reads → cache pays; 1:1 writes with no re-reads → cache is theater.
- 05
Every cache has a price: staleness, memory cost, invalidation machinery, one more failure mode.
- 06
Interview mantra: 'the cache must serve the HOT working set, not everything' — capacity math from 9.9.
Java / Spring map
- →
Spring Cache (@Cacheable, @CacheEvict) is the entry point; Redis/CloudCache as the store.
Code & diagrams
Explain without notes
Given 90% of requests hit 10% of rows, what is the cache hit-rate math and why does it justify a small cache?
Practice
Pick one hot read in your design and specify cache layer, TTL, and size from QPS estimates.
Trade-offs
- ↔
Cache = speed traded against freshness and consistency — the entire phase is about managing this debt.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can compute a cache size from a working-set and state the hit-rate expectation.