⬡ PerformanceIntermediate interactive
Caching
Keep hot data close to cut latency.
cache_aside
hit ratio 0%
client
cache
127
database
app checks cache, falls back to DB
App owns the logic: on a miss it reads the DB and writes the value back into the cache itself.
How it works
Caching stores frequently accessed data in a fast layer — memory, a CDN edge, or a Redis cluster — so repeat requests skip the slow path. The art is in invalidation, eviction policy (LRU/LFU), and choosing between cache-aside, write-through, and write-back.
Mental models
- Cache-aside: the app reads the DB on a miss and back-fills the cache itself.
- Read-through: the cache loads from the DB transparently — the app only sees the cache.
- Write-through keeps cache and DB consistent; write-behind acks first and flushes async (faster, riskier).
- Eviction (LRU/LFU/TTL) decides what to drop when the cache is full.
- Stale data is the price of speed — invalidation is the hard part.
Reach for it when
- Read-heavy workloads
- Session storage
- Rendered-page caching