Caching
A cache is a fast layer in front of a more expensive operation
A system often repeats the same reads: it opens a popular product, a user profile, settings, or a computed result. If every request goes to slower storage or repeats the work, we spend time and resources producing a result we already know.
Caching lets us temporarily keep frequently needed data closer to where it is used. This reduces latency and lowers load on the primary data source, but introduces a new question: how to avoid returning a stale value to the user.
What we will cover
- Caching Basics. We will examine cache hits and cache misses, understand when a cache really speeds up the system, and see the cost of keeping an additional copy of data.
- Cache-Aside. We will look at a scheme where the application checks the cache itself and, on a miss, reads the primary source and stores the result.
- Read-Through. We will see an option where loading missing data is hidden behind the cache interface itself.
- Write-Through. We will examine synchronous writes through the cache together with updating the primary store.
- Write-Back. We will see how deferred writes can make updates faster and what risks appear while data has not yet reached persistent storage.
- TTL and Eviction. We will learn to limit cache lifetime and size so that it does not grow forever.
- Cache Invalidation. We will examine what to do with a cached value after the source data changes.
- Distributed Cache. We will understand how a shared cache works for several application instances at once and what new failure points appear.
We will start with the cache model itself, then move to read and write strategies, after that to data lifetime and freshness, and finally apply the same idea across multiple application instances.
A cache is an optimization, not the source of truth.
Its value depends on how often a repeated read is cheaper to serve from cache than to obtain again from the primary source.