How does caching reduce database load?

What's really being asked

The interviewer wants to know whether you understand why an in-memory store sits in front of a database and how it changes the load profile. It is a fundamentals check on latency, hit ratios, and consistency.

The full answer

A database read, especially a complex join, costs disk I/O and CPU. An in-memory store like Redis serves data from RAM in well under a millisecond. The dominant pattern is cache-aside: the application looks in the cache first, and on a hit returns immediately. On a miss it queries the database, writes the result into the cache with a time-to-live, and returns it. Repeated reads of hot keys then bypass the database, so query volume and connection pressure drop sharply. Good answers also name write strategies: write-through updates the cache and database together, while write-around or explicit invalidation deletes the cached key on a write so the next read repopulates fresh data.

The mistakes people make

Treating the cache as a primary store rather than a volatile speed layer. Forgetting invalidation, which leads to stale reads after updates. Assuming caching always helps; it only helps when reads repeat and data is reused. Caching highly volatile or per-request-unique data wastes memory and lowers the hit ratio.

What usually comes next

How do you pick a TTL? How do you handle a cache stampede when a popular key expires? What is the difference between Redis and Memcached? How do you size the cache and what eviction policy do you choose, such as LRU?

A concrete example

A product page is viewed thousands of times per minute but changes rarely. You cache the rendered product object under the key product:123 with a sixty-second TTL. The first request misses and hits Postgres; the next thousands of requests hit Redis and never touch the database. When an admin edits the product, the write handler deletes product:123 so the following read fetches and caches the updated record.