Cache-aside pattern pros and cons

What's really being asked

The interviewer wants confirmation that you know the dominant caching pattern, where the application orchestrates loading, and can articulate its consistency and operational tradeoffs.

The full answer

In cache-aside, also called lazy loading, the application is responsible for the cache. On a read it first checks Redis; a hit returns immediately, a miss triggers a database read, after which the application stores the value in Redis with a time-to-live and returns it. On a write the application updates the database and then invalidates, or sometimes updates, the corresponding cache key so subsequent reads repopulate fresh data.

PROS Only data that is actually requested gets cached, keeping memory usage efficient. The cache is not on the critical write path, so the system degrades gracefully: if Redis is unavailable, reads simply fall through to the database. It is decoupled from the data store, so it works with any backend.

CONS Consistency is eventual. Between the database write and the cache invalidation, or within a TTL, reads can return stale data, and a missed invalidation leaves a key wrong until it expires. The application carries invalidation complexity and bugs there cause subtle staleness. On a hot key expiring under load, many concurrent misses stampede the database, the cache-stampede problem, mitigated with locks, request coalescing, or jittered TTLs.

What usually comes next

How does it differ from write-through and write-back. How do you size TTLs. How do you prevent stampedes. What happens during a Redis failover.

A concrete example

A user-profile service caches user:42 in Redis with a ten-minute TTL. The first request misses and loads from Postgres; later requests hit the cache. When the user updates their email, the service writes Postgres and deletes user:42, so the next read fetches and recaches the new value.