Every caching design starts with one simple question: who decides what goes into the cache? In the cache-aside pattern, the application does.

On reads, the application checks the cache first. If the value is missing, it reads from the database and stores the result in the cache for next time. On writes, it updates the database first and usually deletes the old cached value.

This pattern is also called lazy loading because data is loaded into the cache only after someone asks for it.

Cache-aside is popular because it works with ordinary key-value stores such as Redis and Memcached. The cache does not need to understand your database tables or business rules. The application owns that logic.

That is both the strength and the cost of the pattern. You get control and flexibility, but every service that reads or writes the data must follow the same cache rules.

This chapter covers how cache-aside reads and writes work, why deleting cached values is usually safer than updating them, how to design keys and TTLs, how to cache "not found" results, and when this pattern is a good fit.