Data-Level Caching Patterns

Data-Level Caching Patterns covers caches that store data artifacts more directly than page or full-response caches do. These are the patterns teams use when they want to reuse entities, query results, rollups, or absence signals rather than fully rendered output. They are often powerful because they sit close to the data model, but that also means they inherit more of the model’s invalidation and consistency complexity.

The four lessons move from simplest to more subtle forms of reuse. The first covers single-entity or record caching. The second covers list and query-result caching, where invalidation becomes much harder. The third covers aggregates and computed summaries, where the cache stores derived meaning rather than canonical objects. The fourth covers negative caching, where even “nothing found” becomes a reusable answer with its own risks.

Use this chapter when the central question is what kind of data artifact should be cached and how its invalidation surface differs from other cache layers. The goal is to leave the child lessons with a clearer sense of where data-level reuse is clean, where it becomes fragile, and how to spot the hidden cost of broad invalidation rules.

In this section

• Entity and Record Caching
  Caching single entities or records by stable identity and on the relationship drift that can make this simple pattern harder than it looks.
• Collection and Query Result Caching
  Caching lists, filtered sets, and query results, where reuse can be high but invalidation often becomes much broader and less predictable.
• Aggregates and Computed Summary Caching
  Caching counts, rollups, and derived summaries so expensive computation is not repeated on every read.
• Negative Caching
  Caching missing or empty results to prevent repeated wasted lookups, while avoiding subtle correctness problems when the underlying data changes.