API cache returns old data after update: split cache key, purge path, and client refresh

When an API returns old data after an update, split the investigation into cache key, purge path, TTL, client refresh, and read source before rewriting the endpoint.

Stale data bugs get expensive when every layer is blamed at once. The server may be returning a cached object, the CDN may be serving an old response, the browser may reuse a previous request, the client store may not refetch, or a read replica may lag behind the writer. The user sees one symptom, but each layer needs a different fix.

Capture one request from the update and one request from the stale read. Record the user or tenant context, route, query string, cache headers, response timestamp, object version, and whether a force refresh changes the result. If the stale response has the new server timestamp but old object fields, the bug is different from a CDN response that never reached the server.

Next, inspect invalidation. What event should purge the cache? Does it include the same key that the read route uses? Are list pages, detail pages, search results, and permissions cached separately? A detail page may update while a list card remains stale because the purge path only covered one key.

The practical rule is to name the freshness promise before fixing the bug. Some fields can tolerate a short TTL. Payment status, permissions, inventory, and safety settings usually cannot. The fix should match that promise.

API cache returns old data after update: split cache key, purge path, and client refresh

// COMMENTS

ON THIS PAGE