After updating data in the database, how would you keep the cache from returning stale data?

Invalidate cached data safely after writes

Explains delete-on-write, versioned keys, event-driven invalidation, and the race conditions around cache freshness.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The simplest approach is to write the database first, then delete or update the relevant cache key. The next read will miss and reload the fresh value. This works well when the app knows exactly which keys depend on the changed data. If many keys are affected, I would prefer a simpler key model, short TTL, versioned keys, or a background invalidation path.

Full answer below

Practice focus

Write path order, cache invalidation, versioned keys, race conditions, retries, and eventual consistency.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Invalidation must connect a committed source-of-truth change to every cached representation derived from it. Timing, retry behavior, and dependency ownership decide how long stale data can survive after a write.
The simplest approach is to write the database first, then delete or update the relevant cache key. The next read will miss and reload the fresh value. This works well when the app knows exactly which keys depend on the changed data. If many keys are affected, I would prefer a simpler key model, short TTL, versioned keys, or a background invalidation path.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid updating the cache before the database commit because that can expose data that never committed. I would also handle the case where the database write succeeds but cache deletion fails. For important paths, the write transaction can record an outbox event or invalidation work item so cache cleanup is retried. If the product tolerates short staleness, a bounded TTL plus best-effort invalidation may be enough.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Updating the cache before the database transaction commits.
Deleting one key while derived lists still contain old data.
Ignoring failed invalidation after a successful write.
Using broad flushes as a normal write-path strategy.

After updating data in the database, how would you keep the cache from returning stale data?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement