Caching stores a copy of frequently-accessed data somewhere fast so you don't recompute or refetch it every time. It's the single biggest lever for reducing latency and database load in read-heavy systems.
Where you can cache
- Client / browser — cache static assets and responses locally.
- CDN — cache static (and some dynamic) content near users. See edge distribution.
- Application / in-memory — a shared cache like Redis or Memcached in front of the database.
- Database — query and buffer caches inside the DB itself.
Write strategies
- Cache-aside (lazy loading) — the app checks the cache; on a miss it reads the DB and populates the cache. Most common.
- Write-through — writes go to the cache and the DB together; cache is always fresh but writes are slower.
- Write-back — writes go to the cache first and flush to the DB later; fast writes but risk of data loss if the cache dies.
- Write-around — writes skip the cache and go to the DB; avoids filling the cache with write-once data.
Eviction policies
Caches are small, so they must evict entries. Common policies: LRU (least recently used — the default choice), LFU (least frequently used), and TTL (expire after a time). LRU is a classic interview implementation using a hash map + doubly linked list.
Cache invalidation — the hard part
Stale data is the price of caching. Strategies include short TTLs, explicit invalidation on write, and versioned keys. The tighter your consistency needs, the more careful invalidation must be — this is genuinely one of the hardest problems in system design.
Frequently Asked Questions
What is the difference between write-through and write-back caching?
Write-through writes to the cache and database at the same time, keeping data safe but writes slower. Write-back writes to the cache first and flushes to the database later, giving fast writes but risking data loss if the cache fails before flushing.
What is cache-aside?
In cache-aside (lazy loading), the application checks the cache first; on a miss it loads from the database and stores the result in the cache. It is the most common caching pattern.
Why is cache invalidation hard?
Because keeping cached copies consistent with a changing source of truth is tricky — invalidate too rarely and users see stale data, too aggressively and you lose the caching benefit.