Caching

A cache keeps a copy of data somewhere faster to reach than its source, so repeat reads skip the slow path to that source. The copy cuts latency and takes read load off the backing store. The copy also costs you two things: memory to hold it, and the risk it drifts from the source while it sits there.

Every caching decision sets a position on those two costs. How much memory you spend sets how much of the working set, the data your application keeps reading, stays resident, and that sets your hit ratio, the share of reads the cache answers without touching the source. How you handle writes and expiry sets how stale a served read is allowed to get. This cluster works through the strategies that fix those positions.

The pages in this cluster

• Caching patterns. Where reads and writes flow: cache-aside, read-through, write-through, write-back, and write-around. The pattern sets who reads the database on a miss and how fresh a write leaves the cache.
• Cache eviction. What to drop when the cache fills: LRU, LFU, FIFO, ARC, and W-TinyLFU. The policy sets the hit ratio you get for a given amount of memory.
• Cache invalidation. How a cached value stops being served once the source changes: TTL and freshness, explicit invalidation, and the stampede that lands when a hot key expires.

Where caching meets the rest of systems

A cache sits in front of a data store, so the store's shape decides what the cache absorbs. A B-tree-backed store answers reads with steady latency, and a cache in front of it cuts the read volume that reaches disk. An LSM-tree already buffers writes in memory and flushes them in the background, which is write-back caching applied inside durable storage. When the cache and the store live on different machines, serving a stale read is a consistency choice, the same trade PACELC names for replicated systems.