intermediate 2 min answer

Users complete an action and the interface still shows the previous value until they refresh. Diagnose.

frontendcachinginvalidation
Show the full answer Hide the answer

What the interviewer is testing

Whether you can locate a staleness bug across the several caches in a modern request path.

The candidates

Client-side query cache not invalidated. The mutation succeeded and the cached query result for the affected data was not marked stale, so the component re-renders from cache. This is the most common cause and the fix is tag-based invalidation after the mutation.

Optimistic update rolled back silently. The interface updated optimistically, the server response differed, and the rollback restored the old value with no error surfaced.

HTTP caching. The GET response carried caching headers, so the browser or an intermediate proxy serves the previous response. Mutations must ensure subsequent reads are not served from an HTTP cache.

CDN caching a response that should be private, particularly if the response lacks private or carries a long TTL.

Read-your-writes violation on the server. The write went to a primary and the subsequent read was served by a replica that had not caught up. Everything client-side is correct and the server returned stale data.

How to distinguish them

Inspect the network: did a request actually go out after the mutation? If not, it is the client cache. If it did and returned the old value, check whether it was served from an HTTP or CDN cache — and if it reached the server, it is a replication lag problem.

That single check splits the space in half immediately.

The fixes

Client: invalidate the affected queries on mutation success, or apply the mutation response to the cache directly. HTTP: correct caching headers on mutable resources. Server: route reads to the primary for a window after a write, or use a version token the client presents on subsequent reads.

What a strong answer adds

Naming this as the distinction between server state and client state. Server state is a cached copy of data owned elsewhere and needs revalidation; treating it as ordinary local state is what produces this class of bug, and adopting a data layer that owns fetching, caching and invalidation eliminates most of it generically.

Common weak answers

Forcing a page reload after every mutation. Disabling caching entirely.