Caching

Cache Basics

For read-heavy applications, storing frequently accessed data in fast memory (e.g., Redis) allows you to skip the DB entirely for some reads. A cache hit on Redis takes ~1ms compared to 20-50ms for a typical DB query, and this speedup is impactful in the order of millions of requests. In a web application, user sessions are typically stored in a distributed cache, allowing the system to quickly retrieve the data when a user makes a request.

Caches are also useful in avoiding expensive computations, e.g., aggregrating data from numerous sources to show on dashboards, showing a user a feed of content from accounts that they follow, etc.

Caches have different eviction policies that come into play when the cache is full, e.g., least recently used (LRU); first in, first out (FIFO); least frequently used (LFU).

Caching requires a solution for invalidating stale data, e.g., user updates their profile in the DB. Strategies include invalidating the cache immediately after writes, using short TTLs, etc.

A cache stampede occurs when a popular cache entry expires and many concurrent requests all miss at the same time and hit the DB. Strategies include locking (only one request regenerates the entry while the rest wait), and staggering TTLs so entries don’t all expire at once.

On a cache outage, e.g., Redis is down, defenses include a small in-process fallback cache, circuit breakers to shed load, or graceful degradation until Redis recovers.

CDN caching is useful for static assets, e.g., images, JavaScript files, etc. In-process caching is useful for small values that change rarely, e.g., feature flags or config data.

Modern caches support different data structures, not just key-value stores. For example, you may want to cache a list of events in a sorted set so that you can easily retrieve the most popular events.

Redis as a Cache

The cache keys are Redis keys and the cached values are Redis values, e.g., cache a product under the key product:123 with the value stored as a Redis Hash containing fields like name, price, etc.

Employ a TTL on each key and Redis guarantees you’ll never read the value of a key after the TTL has expired.

Redis approximates least-recently-used eviction policy by sampling keys rather than tracking exact order.

Redis (and other key-value stores) is susceptible to the hot key problem, e.g., suppose one day there’s a surge of interest for product:123 such that the load on the node housing product:123 is dramatically higher than the rest of the nodes. Strategies for combating this include:

• Each app server keeps a small in-memory cache of the hottest items so that most reads for the hot item never reach Redis. Short TTLs should help in keeping this second cache coherent.
• Store the same data under several keys, e.g., product:123:1 through product:123:10, and have the readers pick a suffix at random. Clients need to see a list of all keys that are duplicated, and every write to a hot item now fans out to all of its copies.

References

1. Core Concepts for System Design Interviews. www.hellointerview.com . Accessed Jun 6, 2026.
2. System Design Key Technologies. www.hellointerview.com . Accessed Jul 14, 2026.
3. Redis Deep Dive for System Design Interviews | Hello Interview System Design in a Hurry. www.hellointerview.com . Jan 16, 2026. Accessed Sep 3, 2026.