Caching patterns, eviction and invalidation

A cache keeps popular data in memory so most reads skip the slower database. The usual pattern is cache-aside: read from the cache first, and on a miss, read the database and put the result in the cache. Write-through updates the cache and the database on every write.

Write-back writes to the cache and saves to the database later, which is faster but can lose data if the cache fails. Memory is limited, so a cache eviction policy decides what to throw out, for example LRU, which drops the least recently used item.

The hard part is stale data: any cached value can be out of date. Choose a TTL (time to live) you can defend, or delete the key when the data changes. Also watch for a cache stampede: a popular key expires and thousands of requests hit the database at once.

Request coalescing (one request refills the key while the others wait) or refreshing early prevents it.