A user reports seeing another account's data on a page; how do you work out which cached copy served that response?

## First, name the failure class A user seeing *their own* stale data is a freshness problem. A user seeing *someone else's* data is a **scope** problem: a response produced in the context of one identity was handed to another. That distinction changes the urgency, the people you involve, and where you look. Freshness bugs live in windows and invalidation; scope bugs live in placement and keys. It also sets an expectation about the symptom's shape. Scope failures are intermittent and traffic-dependent - they need a second request to arrive while a copy from the first is still around - and they usually cannot be reproduced in a development server, where placements that store output are often inactive. ## Reproduce it on purpose Guessing from a screenshot wastes the outage. Build the smallest experiment that can produce the bug: 1. Run against a **production-shaped build**, not a development server, so the stored placements actually exist. 2. Sign in as identity **A**, load the URL, and confirm A's data. This warms whatever copy exists. 3. In a **fresh private window** with no shared storage, sign in as identity **B** and request the same URL. 4. Repeat with B first, then A, to see whether the direction matters. 5. Repeat while signed out entirely - if an anonymous request receives personal data, the copy is fully public and the severity goes up. The private window is doing real work here: it proves the copy is not coming from the reporter's own browser. ## Eliminate placements one at a time | Observation | Placement it implicates | | --- | --- | | Only the original browser shows it; a private window does not | that browser's own payload or history copy | | Wrong only after an in-app navigation, right after a full load | the client-side route payload for already-visited routes | | A second, freshly signed-in browser sees it too | a copy on the server that outlives the request | | An anonymous request sees it | a shared copy keyed without identity, or a layer in front of the origin | | It follows one instance and not another | a copy held in that instance's memory | | It disappears permanently after the stored copy is removed | stored render output rather than a live render bug | Work down the list rather than forming a theory first. Each row is one cheap experiment. ## Signals that a stored copy answered - **Age or debug headers**, where the framework or the host emits them - the most direct evidence available. - **A latency cliff**: a response returning in a millisecond or two when the render normally costs tens or hundreds is not doing the work. - **Data that will not move**: change the underlying record and reload; a response that ignores the change is not being produced from it. - **Byte-identical responses across identities**: if two different signed-in users receive the same bytes including a personal string, one stored copy is answering both. - **A timing pattern**: the wrong data appears only within a window after someone else's visit, then stops - the shape of a copy expiring. Be careful not to over-read a single signal. A fast response can also mean a warm database; a header can be added by something in front of your app. Confirm with at least two. ## Is it a rendered route or a data read? View the response the server actually sent, not the page after client-side code runs. If the other account's string is already in the initial HTML, a rendered route was stored. If the HTML is generic and the wrong data appears afterwards, the copy is a data read reused during the render, or something the client fetched and reused. That determines what you have to remove, and it usually tells you which read is responsible. ## Contain, then fix properly Containment is the immediate move: take that route or read out of the shared copy so every request renders it, and remove the copies already stored. Expect a load increase and watch for it. Then do the actual fix, which is almost always **placement, not keys**: - mark the read as request-bound so it can never be placed in something that outlives the request; - or split the response, keeping the personalised part out of the shared copy while the rest stays reusable; - and add a regression test that performs the two-identity sequence against a production-shaped build, since the bug is invisible to a single-identity test. It is worth finishing the investigation even after the symptom stops. A copy that leaked once was placed wrongly; the same placement decision is usually repeated in several other routes written by the same hand at the same time, and a quick sweep for reads of identity inside anything marked cacheable tends to find them.