Cache-aside pattern with Redis and RDS

WHAT THIS TESTS The interviewer wants to confirm you know the most common caching pattern, where the application, not the cache, controls loading, and that you can name its real tradeoffs.

A GOOD ANSWER COVERS In cache-aside, also called lazy loading, the application first reads from Redis. On a hit it returns immediately. On a miss it reads from the database, writes the result into Redis with a time-to-live, and returns it. On a write, the application updates the database and then invalidates or updates the corresponding cache key so the next read repopulates fresh data. The cache only holds data that has actually been requested, keeping it lean.

TRADE-OFFS Consistency is eventual: between a database write and cache invalidation, or within the TTL, reads can be stale. The application carries the complexity of cache logic, key naming, and invalidation, and bugs there cause subtle stale-data issues. Cache misses are expensive, and if a hot key expires under load many requests stampede the database simultaneously, the thundering-herd or cache-stampede problem, which you mitigate with locks, request coalescing, or staggered TTLs.

COMMON WRONG ANSWERS Describing write-through or write-back and calling it cache-aside, forgetting invalidation on writes, or claiming the cache makes reads strongly consistent.

LIKELY FOLLOW-UPS How does cache-aside differ from write-through. How do you prevent stampedes. How do you pick a TTL. What happens on a cache outage.

ONE CONCRETE EXAMPLE A product page reads from Redis under key product:123. First view misses, so the app loads the row from RDS, caches it for five minutes, and returns it. Subsequent views hit Redis. When an admin edits the product, the app updates RDS and deletes product:123, so the next visitor triggers a fresh load.