Cache invalidation

Overview

Cache invalidation is keeping cached data consistent with its source of truth. It is famously one of the two hard problems in computer science because caches are copies: every write creates a window in which some readers see old data. The design question is how long that window may be and how you shrink it.

The main strategies are expiry (TTL), explicit invalidation on write (delete the key), write-through (update cache and database together), and event-driven invalidation (change data capture streams publish updates). Production systems combine a TTL safety net with explicit or event-driven invalidation.

When to use it

• Any cache in front of mutable data.
• Designing how writes propagate to caches, CDNs, and search indexes.
• Debugging users seeing stale data.
• Choosing TTLs per data type.

Where it shows up in interviews

Where it is used in real software

Key terms

TTL

Entries expire after a time; bounds staleness.

Delete on write

After updating the database, delete the cache key so the next read reloads it.

Write-through

Write to cache and database in the same operation.

CDC

Change data capture: reading the database log to publish every change.

Stale-while-revalidate

Serve the old value while refreshing it in the background.

Safe cache-aside invalidation

1. 1
   Write to the database first

   The database is the source of truth.

2. 2
   Delete the cache key

   Deleting is safer than setting a new value, which can race with other writers.

3. 3
   Readers repopulate on miss

   Next read loads fresh data and caches it with a TTL.

4. 4
   Keep a TTL anyway

   If a delete is lost, the entry still expires.

5. 5
   For strict freshness, use CDC

   Invalidate from the database log so no write path can forget to invalidate.

The classic race condition

Reader A and Writer B, cache-aside with 'set on read'

The stale v1 stays until TTL expiry. Fixes: short TTLs, delayed double delete (delete again after a short delay), leases or version checks on set, or CDC-based invalidation.

Implementation

1async function updateProduct(id: string, changes: Partial<Product>) {2  await db.products.update(id, changes);          // 1. source of truth3  await redis.del(`product:${id}`);              // 2. invalidate4  setTimeout(() => redis.del(`product:${id}`), 500); // 3. delayed double delete closes the race window5  await cdn.purgeByTag(`product-${id}`);          // 4. edge caches6}7 8// Versioned set: only write the cache if our copy is not older than what is cached9async function setIfNewer(key: string, value: Product) {10  const script = `11    local current = redis.call('HGET', KEYS[1], 'version')12    if (not current) or tonumber(ARGV[1]) > tonumber(current) then13      redis.call('HSET', KEYS[1], 'version', ARGV[1], 'data', ARGV[2])14      redis.call('EXPIRE', KEYS[1], 300)15      return 116    end17    return 0`;18  return redis.eval(script, { keys: [key], arguments: [String(value.version), JSON.stringify(value)] });19}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Updating the cache before the database.

  Fix: If the DB write fails, the cache holds data that never existed. Write the DB first.

• No TTL on cache entries.

  Fix: A missed invalidation would otherwise be permanent.

• Forgetting derived caches.

  Fix: A product change may need invalidation of listing pages, search results, and recommendations.

Interview questions

Practice problems