Caching strategies: cache-aside, write-through and write-back
Caching is the cheapest way to make a system faster. Learn the main strategies, when each fits, and the hard parts: invalidation and stampedes.
A cache keeps a copy of data in a fast place (usually memory) so you avoid repeating slow work such as a database query. It helps most when reads are far more common than writes.
Strategies
Cache-aside (lazy loading). The app checks the cache first. On a miss it reads the database, then stores the result in the cache. Simple and the most common. Only data that is asked for gets cached.
Write-through. Every write goes to the cache and the database together. Reads are always fresh, but writes are slower.
Write-back (write-behind). Write to the cache and save to the database later in batches. Very fast writes, but you can lose data if the cache dies before it is saved.
Eviction
Memory is limited, so something must go. LRU (least recently used) removes what has not been touched for longest. LFU removes the least often used. TTL (time to live) removes an item after a set time.
The hard problems
- Invalidation. When the source data changes, stale cache entries must be updated or deleted. The safe default is a short TTL plus deleting the key on write.
- Cache stampede. A popular key expires and thousands of requests hit the database at once. Fixes: lock so only one request rebuilds it, add random jitter to TTLs, or refresh before expiry.
- Cold start. An empty cache sends all traffic to the database. Warm it before a big launch.
Where caches live
Browser, CDN, reverse proxy, application memory, and a shared store such as Redis or Memcached. Each layer cuts load on the next one.
Takeaway: start with cache-aside and a TTL, cache read-heavy data, and plan for invalidation from day one.
Part 5 of 15 in the System Design series. Previous: Load balancer: what it does and how to choose an algorithm.
