The Cache Invalidation Nightmare

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton. If you keep data too long, the user sees old info. If you delete it too soon, your database crashes from the load.

1. Time to Live (TTL)

Assign an expiration time to every cache key. Pros: Simple. Cons: Data is guaranteed to be stale for the duration of the TTL.

2. Event-Based Eviction

When the database record is updated, the app explicitly deletes the corresponding cache key. This provides the best consistency but is prone to "Ghost Keys" if the delete operation fails.

3. Cache Stampede (Dog-piling)

What happens when a very popular key (e.g., the Homepage) expires? 10,000 requests all "Miss" at the same time and hit the database simultaneously. To prevent this, use Cache Locking or Background Revalidation (serve stale data while one worker refreshes the cache).

4. Interview Mastery

Q: "How do you handle 'Hot Keys' in a distributed cache?"

Architect Answer: "A Hot Key is a single celebrity profile that everyone is trying to access, overwhelming one specific Redis shard. We fix this by: 1) **Local Caching (Multi-tier)**: Cache that one specific key in the server's own RAM for 1 second. 2) **Key Salting**: Store the same data across multiple keys (`user_1_shard_A`, `user_1_shard_B`) and pick one randomly."