Concept questionMedium~7 minProduct Features / 9 of 19

Interview question

After a user creates, edits, or deletes data, how would you keep the frontend UI consistent?

Invalidate frontend cache after mutations

Explains refetching, targeted invalidation, stale data, optimistic updates, server truth, and user feedback after mutations.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would decide what the mutation response returns and which cached views are affected. For a simple edit, the API can return the updated resource and the UI can update the detail cache and invalidate related lists. For create or delete, I often invalidate list queries and refetch because ordering, filters, and totals may change. The UI also needs clear success, failure, and pending states.

Full answer below

Practice focus

Client cache invalidation, stale data, mutation responses, optimistic updates, refetch strategy, and consistency trade-offs.

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
Most full-stack bugs after mutations are stale UI bugs. The backend changed, but the list, detail, counters, badges, or navigation still show old state.
I would decide what the mutation response returns and which cached views are affected. For a simple edit, the API can return the updated resource and the UI can update the detail cache and invalidate related lists. For create or delete, I often invalidate list queries and refetch because ordering, filters, and totals may change. The UI also needs clear success, failure, and pending states.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid pretending the client cache is the source of truth. Optimistic updates can make small interactions feel fast, but they need rollback when the server rejects the mutation. Targeted cache updates are efficient but easy to miss when many views depend on the same data. Refetching is simpler and safer, but can feel slower. The right choice depends on mutation frequency, UX expectations, and how expensive the API calls are.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would watch for stale data after role changes, cross-tab edits, background jobs, and server-side recalculation. Some data needs realtime updates or polling; other data can be eventually consistent with a visible refresh. I would standardize query keys, mutation helpers, and invalidation rules so every feature does not invent its own pattern. Metrics and support logs should make it clear whether the server accepted the mutation and what the UI fetched afterward. I would also document the invalidation rule near the mutation helper so future screens reuse the same cache keys instead of creating hidden stale-data bugs.

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 only the current component and leaving other views stale.
Using optimistic updates without rollback.
Refetching everything after every small mutation.
Ignoring counters, badges, and related lists.

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

Details

Cannot identify affected cached queries.
Treats local cache as final server state.
No error recovery after a failed mutation.
Mutation response shape is not useful to the UI.

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 refetch instead of patching cache?
How would rollback work for an optimistic update?
What data becomes stale after a delete?

Continue the section

Next in Product Features: Optimistic UI

Step 10 of 19

Choose optimistic UI or server-confirmed updates

Opening drill

Concept questionMedium~7 minProduct Features / 9 of 19

Interview question

After a user creates, edits, or deletes data, how would you keep the frontend UI consistent?

Invalidate frontend cache after mutations

Explains refetching, targeted invalidation, stale data, optimistic updates, server truth, and user feedback after mutations.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Client cache invalidation, stale data, mutation responses, optimistic updates, refetch strategy, and consistency trade-offs.

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
Most full-stack bugs after mutations are stale UI bugs. The backend changed, but the list, detail, counters, badges, or navigation still show old state.
I would decide what the mutation response returns and which cached views are affected. For a simple edit, the API can return the updated resource and the UI can update the detail cache and invalidate related lists. For create or delete, I often invalidate list queries and refetch because ordering, filters, and totals may change. The UI also needs clear success, failure, and pending states.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid pretending the client cache is the source of truth. Optimistic updates can make small interactions feel fast, but they need rollback when the server rejects the mutation. Targeted cache updates are efficient but easy to miss when many views depend on the same data. Refetching is simpler and safer, but can feel slower. The right choice depends on mutation frequency, UX expectations, and how expensive the API calls are.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would watch for stale data after role changes, cross-tab edits, background jobs, and server-side recalculation. Some data needs realtime updates or polling; other data can be eventually consistent with a visible refresh. I would standardize query keys, mutation helpers, and invalidation rules so every feature does not invent its own pattern. Metrics and support logs should make it clear whether the server accepted the mutation and what the UI fetched afterward. I would also document the invalidation rule near the mutation helper so future screens reuse the same cache keys instead of creating hidden stale-data bugs.

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 only the current component and leaving other views stale.
Using optimistic updates without rollback.
Refetching everything after every small mutation.
Ignoring counters, badges, and related lists.

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

Details

Cannot identify affected cached queries.
Treats local cache as final server state.
No error recovery after a failed mutation.
Mutation response shape is not useful to the UI.

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 refetch instead of patching cache?
How would rollback work for an optimistic update?
What data becomes stale after a delete?

Continue the section

Next in Product Features: Optimistic UI

Step 10 of 19

Choose optimistic UI or server-confirmed updates

After a user creates, edits, or deletes data, how would you keep the frontend UI consistent?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

After a user creates, edits, or deletes data, how would you keep the frontend UI consistent?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section