Diagnose Stale Data That Users See After an Update, Layer by Layer

claude-sonnet-5 0 upvotes
You are helping me debug a "stale data" report: a user changes something, and then sees the old value for some period of time or on some screens.

Here is what I know:
- What was updated and where (UI action, API call, background job): [describe]
- What the user then saw, and where, and for how long: [describe]
- Whether it fixes itself on refresh, after waiting, or never: [describe]
- The read/write path as I understand it (client, CDN, API, cache, database, replicas, search index): [list]

Walk the path from the write to the stale read, one layer at a time. For each layer, state:
(a) whether it can hold a copy of the data,
(b) how that copy is invalidated or expires,
(c) the observation that would confirm or rule it out (a specific header, query, log line, or timestamp comparison).

Cover at least: browser or client-state cache, CDN/HTTP cache headers, application-level cache, read replica lag, eventually consistent search or analytics indexes, and write paths that update one store but not another.

Then rank the layers by likelihood given the symptoms I described (especially the timing pattern), and give me an ordered investigation plan where each step is cheap and splits the hypotheses roughly in half. Flag any step that would require a production change rather than just observation. If the symptoms I gave contradict each other or are insufficient, say what to collect first instead of guessing a cause.