Take over a web app that's gone off the rails.

Caching in a web app is rarely one thing. Depending on how it was built, it can live at several layers between the database and the visitor's screen — the browser's own cache, a CDN or edge in front of the app, a page or response cache on the server, and an application-level cache over the data itself. Which of these an inherited app actually relies on is seldom written down anywhere, and that's where most "caching chaos" reports start: not one cache misbehaving, but a fix aimed at the wrong layer.

Each layer has its own lifetime and its own way of being cleared, and they don't coordinate. A CDN might hold a page for an hour; the application's data cache might key off a completely different trigger; the browser might sit on a response until someone hard-refreshes. Change the underlying data and one layer updates while another keeps serving the old version — so the site shows something stale even though the code that produced it is correct.

This is why a correct fix can still look like it did nothing. Someone clears the application cache, the data is right on the server, and the visitor still sees the old page because a layer further downstream — the CDN, or their own browser — never got the memo. Working out which layers an inherited app actually leans on, and how each one is invalidated, is the first diagnostic step, not the last: touch one and leave the others, and to whoever applied the fix it looks like nothing changed at all.