Caching

Dated Jun 6, 2026; last modified on Sat, 06 Jun 2026

Notes

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.

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.

How does caching work for feature flags? Don’t different users see different feature flags? A server instance would be serving many users with different feature flag configs.

References

  1. Core Concepts for System Design Interviews. www.hellointerview.com . Accessed Jun 6, 2026.