Concept questionMedium~7 min

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design invalidation around dependencies. A product update might affect product detail, search filters, category pages, recommendations, and tenant-specific views. Trying to delete every possible derived key can become fragile. Versioned keys, cache namespaces, materialized read models, or event-driven rebuilds can make invalidation more reliable. I would add tests for write-read behavior and telemetry for stale reads, invalidation failures, and reload spikes.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Thinks TTL alone solves all freshness cases.
Cannot explain write/cache ordering.
No answer for derived or list caches.
No retry path for failed invalidation.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would you use versioned cache keys?
What if cache deletion fails after the database commit?
How would you invalidate cached search results?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Outbox Pattern

Concept questionMedium~7 min

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design invalidation around dependencies. A product update might affect product detail, search filters, category pages, recommendations, and tenant-specific views. Trying to delete every possible derived key can become fragile. Versioned keys, cache namespaces, materialized read models, or event-driven rebuilds can make invalidation more reliable. I would add tests for write-read behavior and telemetry for stale reads, invalidation failures, and reload spikes.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Thinks TTL alone solves all freshness cases.
Cannot explain write/cache ordering.
No answer for derived or list caches.
No retry path for failed invalidation.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would you use versioned cache keys?
What if cache deletion fails after the database commit?
How would you invalidate cached search results?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Outbox Pattern

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 practice

Go deeper

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 practice

Go deeper