캐시 무효화 전략

Caching speeds up reads, but a cache that serves stale data can be worse than no cache at all. Cache invalidation is the discipline of removing or refreshing entries when the underlying source of truth changes.

It is famously hard: there are only two hard things in computer science, and one of them is cache invalidation.

The simplest strategy is time-to-live. You accept that data may be stale for at most N seconds.

• SET key value EX 60 expires after 60 seconds
• EXPIRE key 60 sets a TTL on an existing key
• TTL key shows remaining seconds

In write-through caching, every write goes to both the database and the cache in the same operation. Reads are always fresh, at the cost of slower writes.

The application is responsible for keeping the two in lockstep.

Write-behind (write-back) writes to the cache first and flushes to the database asynchronously. Writes are fast, but you risk data loss if Redis goes down before the flush.

Use a queue or stream to buffer pending writes.

The cache-aside + delete pattern: on every update to the database, delete the cached key. The next read repopulates it.

This avoids serving stale data and is simpler than keeping the cache value in sync.

Deleting the key (instead of overwriting it) avoids a race condition: two concurrent updates could otherwise write values in the wrong order. With deletion, the next read always pulls the latest from the source of truth.

Instead of invalidating, bump a version number embedded in the key. Old keys expire naturally via TTL while new reads use the new key.

Publish an invalidation event whenever data changes. Other application nodes subscribe and clear their local caches. This pairs Redis Pub/Sub with caching.

Group related keys under a tag set. When a tag becomes invalid, delete all member keys in one sweep.

• SADD tag:user:42 product:1 product:2
• On change: SMEMBERS tag:user:42 then DEL each

When a hot key expires, many requests may hit the database at once (a cache stampede). Mitigate with a short lock, probabilistic early expiry, or serving slightly stale data while one worker refreshes.

There is no single best approach:

• TTL for tolerable staleness
• Delete-on-write for correctness
• Event-driven for multi-node consistency
• Versioning for bulk config changes

You learned the major cache invalidation strategies: TTL expiry, write-through, write-behind, delete-on-write, versioned keys, event-driven, and tag-based invalidation, plus how to avoid cache stampedes. Pick the strategy that matches your tolerance for staleness and your consistency needs.