Data & storage

Caching

Keep copies of frequently read data in fast memory so most requests never reach the database.

Most large systems are read-heavy and a small fraction of data gets most of the reads. Putting that hot data in an in-memory store (or at a CDN edge) cuts latency from milliseconds to microseconds and shields the database from load.

The hard parts are deciding what to cache, how long to keep it, and what happens when the underlying data changes.

See it in action

Step through the scenarios on the diagram.

1/2The app requests product 42.

App: — Asks for product 42
Product service: — Applies cache-aside
Cache: — Hot products, 5-minute TTL
Database: — Source of truth

How it works

Cache-aside: read the cache; on a miss, read the DB and populate the cache. The most common pattern.
Write-through: write to cache and DB together so the cache is always fresh.
Write-back: write to cache and flush to the DB later — fast but risks loss.
Eviction (LRU/LFU) and TTLs bound memory; versioned keys avoid explicit invalidation.

Trade-offs

Stale reads until the TTL expires or the key is invalidated.
Cache stampede when a hot key expires — use request coalescing or early refresh.
Another system to run, monitor and size.

Caching

See it in action

How it works

Trade-offs

Seen in

Components involved

Related concepts