Caching Strategies
Keep frequently read data close and fast, and decide carefully how it stays fresh.
A cache stores the result of an expensive operation — a database query, an API call, a rendered page — so the next request can be served from memory in a fraction of the time.
Caching is the single most effective performance tool, and also a common source of bugs. The hard parts are invalidation (when is cached data wrong?) and isolation (whose data is this?).
Diagram
Key concepts
- Cache-aside (lazy loading)
- The app reads the cache, and on a miss loads from the database and writes the cache. The most common pattern.
- Write-through
- Writes go to the cache and the database together, so the cache is always fresh. Slower writes.
- Write-behind
- Writes go to the cache and are flushed to the database later. Fast, but data can be lost on a crash.
- TTL
- Time to live — the cache entry expires automatically after a set period.
- Eviction
- When memory is full, entries are removed, typically least recently used (LRU) first.
- Cache stampede
- Many requests miss at once and all hit the database. Solved with locking, request coalescing or early refresh.
Trade-offs
Benefits
- Huge latency reduction for repeated reads
- Protects the database from read load
- Absorbs traffic spikes
Costs
- Stale data until invalidated or expired
- Another system to run, size and monitor
- Hidden bugs when keys miss a tenant or user ID
Use it when
- Read-heavy data that changes rarely: catalogues, settings, profiles
- Expensive computations or slow third-party calls
- Session storage for stateless servers
Common mistakes
- Cache keys without tenant or user scope — one customer sees another’s data
- No TTL, so stale data lives forever
- Caching errors or empty results without meaning to
Interview questions
Q1How do you keep a cache consistent with the database?
Usually by deleting the cache key when the data changes and letting the next read repopulate it, combined with a TTL as a safety net. Strong consistency needs write-through or no cache for that data.
Q2What is a cache stampede and how do you prevent it?
A popular key expires and thousands of requests hit the database at once. Prevent it with a lock so one request rebuilds the value, staggered TTLs, or refreshing before expiry.
Q3Where can caching happen in a web system?
Browser, CDN edge, reverse proxy, application memory, a distributed cache like Redis, and the database’s own buffer pool.
Related lessons
Scalability & Performance
Content Delivery Networks (CDN)
Serve static content from edge servers near your users instead of a single origin.
Data & StorageDatabase Scaling & Replication
From one database server to replicas, partitions and shards — in the order you should reach for them.
APIs & SecurityImproving API Performance
Pagination, caching, compression, async processing and connection pooling.