Cache Invalidation

System Design FundamentalsSeniorcachingsystem-design

The Question

What are the common cache invalidation strategies?

What a Strong Answer Covers

• Thundering herd defined + fix.

Senior-Level Answer

Cache invalidation is one of the hardest problems in distributed systems because you must balance consistency, availability, and performance simultaneously. The four primary strategies each fit different access patterns.

**TTL (Time-To-Live) expiration** is the simplest: every entry carries a max-age, and the cache discards it automatically. It requires no coordination with the source of truth but tolerates stale data for up to the TTL window. Use it when slight staleness is acceptable—CDN responses, DNS records, rate-limit counters.

**Event-driven (active) invalidation** purges or updates cache entries immediately when the underlying data changes. This is achieved via cache-aside updates on write, pub/sub events (e.g., Redis keyspace notifications), or explicit purge API calls. It minimizes stale reads but introduces coupling between the write path and cache management logic.

**Write-through** keeps the cache always in sync by writing to both the cache and the database synchronously on every mutation. Read latency stays low; write latency increases slightly. The cache is never stale, but every write pays the double-write cost even for data that is never re-read.

**Write-behind (write-back)** acknowledges the write to the client after updating the cache only, then flushes to the database asynchronously. This maximizes write throughput but risks data loss if the cache node dies before the flush. It is appropriate for high-throughput, loss-tolerant workloads like analytics counters.

**Cache-aside (lazy loading)** lets the application populate the cache on cache miss. On invalidation, the application simply deletes the key; the next read repopulates it. This avoids loading rarely-accessed data but can cause a thundering herd when many keys expire simultaneously—mitigated with jitter on TTLs or probabilistic early expiration.

In practice, production systems layer strategies: a short TTL provides a safety net, event-driven purges handle critical updates immediately, and write-through is reserved for hot, frequently-read data. The key engineering decision is choosing the acceptable staleness window and whether consistency must be strong, eventual, or bounded-staleness.

What Separates a 2/3 from a 3/3

Common Mistakes

• Treating TTL as the only strategy without discussing active invalidation.
• Confusing write-through with write-behind—forgetting write-behind has durability risk.
• Not mentioning thundering herd when many TTLs expire simultaneously.
• Describing invalidation without acknowledging the race condition between a cache read and a subsequent write.

Follow-Up Questions

• How would you prevent a thundering herd after a mass cache expiration? — Discuss jitter on TTLs, probabilistic early expiration (XFetch algorithm), and request coalescing.
• In a write-through strategy, how do you handle a cache write that succeeds but the database write fails? — Point to two-phase approaches, compensating transactions, or treating the cache write as tentative until DB confirms.
• When would you choose event-driven invalidation over TTL, and what infrastructure does it require? — Discuss change-data-capture (CDC), message queues, or database triggers as the plumbing for event-driven purge.
• How does cache invalidation interact with distributed caches like Redis Cluster? — Mention keyspace notifications, slot ownership, and that purge must target the correct shard.

Related Questions

• Redis Caching Patterns
• Vertical vs Horizontal Scaling
• API Versioning
• SLOs vs SLAs
• Availability — Five 9s