If POSTed GraphQL responses are never stored by HTTP caches, why can a field still return stale data?

## The tier did not vanish; it moved The single-endpoint POST shape removes the HTTP cache tier. It removes nothing else. Caching is not a feature of HTTP that a system either has or lacks — it is a pressure that appears anywhere the same expensive answer is computed twice, and closing one outlet just routes it to another. After the move, a GraphQL response can carry stale bytes from at least five places: * **The client's own store.** A client library that keeps results locally will happily render a value it fetched earlier without asking again. This is invisible to the network entirely — no request is even made. * **A server-side response cache.** Some servers keep whole results keyed by operation plus variables plus a viewer identity, which is the same idea as an HTTP cache reimplemented above the transport, where the operation is finally readable. * **A per-request batch loader.** Within a single execution, a loader that has already fetched an object by id will return the same instance for a later field. It is short-lived by design, but inside one long-running operation it does mean two selections of the same entity are the same snapshot. * **A shared data cache.** The key-value cache your repository layer consults before touching the store of record. This is usually the biggest one and usually the one holding the stale value. * **The store of record itself.** A read replica lagging its primary, or a precomputed rollup refreshed on a schedule, serves data that was true a while ago. It is not called a cache, but it behaves as one for every purpose that matters here. ## A worked incident A solar-array telemetry graph has a 340 ms p99 budget on the site dashboard operation. To hold it, the team put the expensive aggregate behind a rollup refreshed every 60 seconds, while identity and status fields kept reading the primary directly: ```graphql query SiteDashboard($site: ID!) { site(id: $site) { name totalOutputKw # served from a 60s rollup lastReadingAt # read live from the primary inverters { id status } } } ``` Operators report that a site shows `lastReadingAt` seconds old while `totalOutputKw` is visibly wrong — by their measurement, up to 47 seconds behind. The first instinct is to blame a cache in the network path, so someone purges the CDN and nothing changes, which is unsurprising: the CDN never held anything, because the request is a POST to one URL. The actual cause is that **one response is not one snapshot**. Each field is resolved separately, and each resolver chose its own tier. HTTP caching, whatever its limits, gave you the opposite guarantee: a stored response was a single coherent capture of one moment with one `Age`. Field-level resolution against heterogeneous tiers gives up that coherence, and the resulting artefact — internally inconsistent data inside a single successful 200 — is one this shape produces and REST largely does not. ## What you lose operationally, and what to build back Three capabilities go away with the HTTP tier, and each has to be rebuilt inside the service if you want it: **Observability.** There is no `Age`, no `X-Cache: HIT`, no per-URL hit rate. The infrastructure dashboard your ops team already runs reports one hot endpoint at 100% origin traffic and tells you nothing else. Recovering it means emitting your own signals: a per-resolver cache-hit metric tagged with the field, and, when it matters to consumers, a provenance value returned in the response's extensions entry or as an explicit field such as `computedAt` on the aggregate. **Purging.** You cannot invalidate by URL, because the URL is the whole API. Invalidation has to happen at whatever internal key the data cache actually uses — an entity identity, a tenant, a tag — and that is application code someone must write and test. **A single freshness contract.** Under URL caching, one lifetime governed one response. Now every tier has its own lifetime and they compose in ways nobody wrote down. The practical discipline is to make freshness an explicit part of schema design: decide per field what age is acceptable, name the aggregate field in a way that admits it is an aggregate, and prefer returning an explicit timestamp over letting a client assume everything in the payload is simultaneous. ## How to answer this in an interview Do not stop at "caching moved inside". The sharp version is: the HTTP tier's real contribution was not only speed but a **coherent, observable, purgeable unit** — one response, one age, one key. Losing it costs those three properties independently, and a field returning stale data is the symptom of the first two failing at once. Then name where you would actually look, in order: the client store, the server response cache, the shared data cache, the replica or rollup — and say how you would tell them apart, which is by whether a request left the client at all, and whether the value changes when you bypass each tier in turn.