How should teams implement request-scoped query caching without rewriting every query?

Use a request-local cache provider that sits under the database adapter, so repeated reads can reuse the same query result automatically. The key is to inject the cache into the request lifecycle, not into individual query builders, so you preserve existing service code while reducing duplicate database reads.

How request-scoped query caching works in practice

The cleanest implementation is to place the cache below your database adapter, where it can intercept repeated reads for the duration of a single request. That lets existing service and repository code keep issuing the same queries while the adapter returns a cached result on the second call. The design goal is locality: cache the result set for one request, then discard it automatically when the request ends.

This works best when the cache key is derived from the actual query shape and parameters, not from the calling function. Two callers asking for the same data should hit the same cached entry, while different predicates, pagination values, or transaction contexts should resolve to different entries. The adapter layer is usually the right place to normalize that logic because it already sees the final SQL or query AST.

Request scoping also changes the failure mode. Instead of creating a long-lived shared cache that can serve stale data across users or threads, you keep the blast radius limited to one request. That preserves correctness for mutable data while still removing duplicate reads caused by repeated resolver calls, nested service invocations, or repeated lookups inside the same page render.

Where to place the cache so you do not rewrite queries

Do not push caching into every query builder or service method unless you are intentionally changing business logic. A request-local provider works better because it can be injected once at the request boundary, then shared by all downstream data-access code. In practice, that means your request middleware, GraphQL context, or HTTP handler creates the scoped cache and hands the adapter a cache-aware session.

The adapter should own the decision to read through the cache, write to it, or bypass it. That keeps the calling code simple and avoids a wave of call-site changes. It also makes it easier to preserve invalidation rules, because the cache can be tied to the exact request lifecycle rather than to whichever component happened to call the database first.

For teams that want a deeper implementation pattern, the main architectural idea is the same as the one used in the Permission-Aware RAG Guide: keep the policy or caching decision at the shared access layer, not scattered across every caller. When access behavior is centralized, existing application code changes less and the control is easier to reason about.

What good request-scoped caching needs to get right

Request-scoped caching only works well when the cache is narrowly bounded and semantics are explicit. Reads should be safe to reuse, but writes, mutations, and transaction-sensitive queries usually need bypass logic or invalidation. If a query depends on a transaction snapshot, user context, tenant context, or row-level permissions, those inputs must be part of the cache key or the cache should be skipped entirely.

Teams also need to think about observability. If the cache is hidden too deeply, developers may assume they are testing fresh database reads when they are not. Useful implementations expose cache-hit metrics, a way to disable caching for debugging, and clear rules for when identical-looking queries are not actually equivalent.

A practical comparison is the same one that underpins the Authorisation Models Guide: the control should reflect the context that actually changes the outcome. In query caching, that context is not the caller, it is the request, the query shape, and any data or permission boundaries that affect correctness.

Risk and Threat Considerations

Request-scoped caching reduces duplicate reads, but it can create correctness and exposure issues if the scope is too broad or the cache key is too loose. The main risk is serving a result that was valid for one user, tenant, transaction, or point in time but should not be reused for another context.

Failure mechanism: A shared or poorly keyed cache can blur request boundaries, allowing stale, cross-context, or permission-sensitive data to be reused when it should have been recomputed.

Impact: That can produce data leakage, inconsistent reads, debugging confusion, or hard-to-reproduce production defects, especially when the same query text hides different security or transaction semantics.

Practitioner Guidance

What to prioritise: Start by defining the exact cache boundary, then decide which query classes are safe to reuse inside that boundary. Treat read-only, duplicate lookups as the initial target, and keep mutation paths, transaction-dependent reads, and context-sensitive queries out until you have explicit rules for them.

What to verify: Confirm that the cache key includes every input that can change the answer, including tenant, user, locale, permission scope, pagination, and transaction state where relevant. If two calls should not be interchangeable, they should not be able to land on the same cache entry.

Practitioner takeaway: The safest pattern is a cache that is invisible to callers but strict about context, because the implementation detail should disappear while the correctness boundary remains obvious.

Related resources from NHI Mgmt Group

• How should banking teams implement authorization without embedding rules in every service?
• How should teams implement query-plan based authorization without creating hidden access gaps?
• How should teams reduce IAM technical debt without rewriting every application?
• How should security teams implement semantic caching in customer-facing AI systems without risking wrong answers or data leakage?