The first design question in caching is simple:

Who decides what goes into the cache?

In the cache-aside pattern, the application makes that decision.

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. On writes, the application updates the database and usually deletes the affected cache entry.

This pattern is also called lazy loading because data is cached only after something 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 know your database schema. Your application owns the logic.

That is both the strength and the cost of the pattern.

This chapter walks through how cache-aside reads and writes work, why invalidation usually means deletion, key design and TTL choices, null caching, failure handling, and when the pattern is a good fit.