Designing a Client-Side Cache

The plain-language idea

This is the design layer above HTTP: the kind of cache a data-fetching library like React Query or Apollo builds on top of, not the Cache-Control/ETag mechanics that decide whether a byte stream gets re-downloaded. Three design questions define it:

• Cache key design — what uniquely identifies one cached entry. Usually a combination of the resource type, its id, and any query parameters that change the response shape (["orders", { status: "open", page: 2 }] is a different cache entry from ["orders", { status: "closed" }], even though both fetch "orders").
• Invalidation strategy — when a mutation happens, which cached entries does it affect, and how do they get refreshed. This is the classic "there are only two hard problems in computer science: cache invalidation and naming things" territory, and it's worth naming that honestly in an interview rather than pretending it's a solved problem.
• Staleness tolerance — a genuine per-feature decision, not a global setting. A user's own profile data can usually be served stale while a background refetch quietly updates it, with no visible harm. A stock price or an inventory count at checkout cannot — showing a stale number there is a real correctness problem, not a minor UX rough edge.

See it in a real thing: normalized cache vs. per-query cache

The same product appears in two places: a product-page query and a search-results query.

BackNext

Say a product page and a search results list both display the same product. A per-query cache stores each fetch's result independently — the product-page query and the search-results query each hold their own copy of that product's data. It's simple to build, but when a mutation updates the product's price, only the query that mutation directly targeted gets refreshed; the other cached copy quietly goes stale until it's separately refetched. A normalized cache stores the product entity once, keyed by its id, with every query that references it pointing at that one shared copy — updating the price in one place updates every screen showing that product automatically, because there's only one copy to update.

What people usually miss

Watch out

• This is a distinct layer from HTTP caching, not a restatement of it. An app can have perfect Cache-Control/ETag behavior and still show stale, inconsistent data on screen if the application-level cache's invalidation strategy is wrong — they solve different problems.
• Staleness tolerance isn't one global setting. A strong answer treats it per-feature: stale-while-revalidate is a genuine, deliberate choice for low-stakes data, not a fallback applied everywhere out of laziness.
• Invalidation is genuinely hard, and saying so is a stronger answer than pretending otherwise. A candidate who acknowledges the real difficulty and proposes a concrete, scoped strategy (invalidate this specific key, or refetch this specific query, on this specific mutation) is more convincing than one who claims a fully general solution exists.
• A per-query cache isn't wrong, it's a tradeoff. It avoids the id-resolution machinery a normalized cache needs, at the cost of the same entity being able to go inconsistent across views after a partial update — naming that tradeoff explicitly is the actual skill.

Why this matters in interviews

"How would you design the caching layer for a data-fetching library, or for this specific feature's fetched data?" is a real system design prompt, and the strong answers separate cache key design, invalidation, and staleness tolerance as three distinct decisions rather than treating "caching" as one monolithic checkbox.