Why cache at all

The problem

Reading the same data from a database a million times is wasteful and slow.

The idea

Store frequently-read results in fast memory close to where they're needed, so most reads skip the expensive path.

How it works

A cache (e.g. Redis) holds hot data in RAM. On a read you check the cache first; a hit returns instantly, a miss falls through to the DB and populates the cache.

The tradeoff

Cached data can be stale, and memory is finite — you must decide what to keep and for how long.

In the wild

Reddit, Twitter, basically every read-heavy site serves most reads from cache, not the DB.

Interview deep dive

Flow

1. Request asks for a hot object by key.
2. App checks Redis or an edge cache before touching the database.
3. On miss, app reads the source of truth and fills cache with a TTL.
4. Future reads hit memory until invalidation or expiry.

Watch for

• Cache hit ratio matters more than cache size alone.
• A stale cache is tolerable for profiles, dangerous for balances.
• A hot key can overload one cache node.

Interviewer trap

Push beyond "add Redis": name the key, TTL, invalidation path, and source of truth.

Related Academy