Invalidation: TTL, versions, and the delete that arrives late

Four mechanisms

In practice you combine them: a short TTL as a backstop, event-driven deletion for promptness, and versioned keys where correctness matters most. The TTL is the insurance policy — it guarantees that every mistake eventually heals.

The version-key trick

Instead of storing product:42, store product:42:v7, where 7 comes from the row's version column or a monotonic update counter. A writer bumps the version in the database; readers derive the key from the version they were given. Old entries become unreachable immediately and expire on their own. There is no delete to race, because the key name itself changed.

read(id):  v = version_store.get(id)      # e.g. Redis or the row itself
           hit = cache.get(f"product:{id}:v{v}")
           if hit: return hit
           row = db.read(id)
           cache.set(f"product:{id}:v{row.version}", row, ttl=600)
           return row

write(id): row = db.update(...)  # version increments inside the transaction
           version_store.set(id, row.version)

Event-driven invalidation, done honestly

Publish a change event when a row changes, and have every cache consumer delete the relevant keys. The failure mode is that the event is lost, delayed, or applied twice.

Bounded staleness is a product conversation

Write the requirement as a number: profile edits visible within 5 seconds, inventory counts within 30 seconds, recommendation rails within 15 minutes. Then choose a mechanism that provably meets it. Without a number, every discussion becomes a contest of intuition, and someone eventually ships a cache with a one-hour TTL in a flow that needed one second.