Request-scoped query caching cuts duplicate database reads by 30%

At a glance

What this is: WorkOS describes a request-scoped database query cache for NestJS and TypeORM that cut duplicate reads by about 30% while avoiding stale results and cross-request leakage.

Why it matters: For IAM and platform teams, the pattern shows how application-layer read amplification can be reduced without changing business logic, provided cache scope and invalidation match request boundaries.

Context

Request-scoped query caching is a pattern that keeps repeated database lookups inside a single HTTP request from hitting the database more than once. In this case, the problem was not raw database failure but repeated reads caused by shared service layers and cross-cutting helper calls inside a monorepo.

For identity and access platforms, that matters because entitlement checks, team membership lookups, and environment settings are often revisited several times in one request path. A cache that is too broad creates staleness risk, while a cache that is too narrow misses the performance win entirely.

WorkOS said the implementation had to respect three constraints: no mass query rewrites, request-only lifetime, and immediate invalidation on writes. That combination makes the article useful as an operational pattern rather than just a performance anecdote.

Key questions

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

A: 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.

Q: Why does request-scoped caching reduce staleness risk compared with a shared cache?

A: A request-scoped cache expires naturally when the HTTP request ends, so it cannot leak older state into a later request. That does not eliminate freshness concerns inside the request, which is why writes still need to clear the cache immediately. Scope reduces exposure, but invalidation preserves correctness.

Q: What are the signs that query duplication is hurting backend performance?

A: Look for repeated reads of the same user, entitlement, or environment data inside one request path, especially when logs show the same SQL firing multiple times during one page load. Database-side statistics are the best confirmation, because they show whether the application is actually executing redundant queries.

Q: What should teams do when a cache improves performance but might hide fresh writes?

A: Treat write paths as invalidation points and clear the request cache before any read can reuse stale state. If the application needs consistent reads after mutation, the cache must be bounded to the request and coupled to the repository layer so freshness always wins over reuse.

Technical breakdown

How request-scoped query caching works in a NestJS and TypeORM stack

The pattern places a cache object in request-local storage, then lets repeated query executions read from that local map instead of reissuing the same SQL. In practice, NestJS provides request-scoped dependency injection, while continuation-local storage preserves the cache across async callbacks and helper layers. TypeORM then uses a custom query result cache provider to intercept reads and stores query results keyed by the query string. The key architectural point is scope: the cache exists only for the lifetime of one request, so it can accelerate repeated lookups without becoming a shared application cache.

Practical implication: keep the cache boundary aligned to the HTTP request if you want reuse without introducing cross-request data leakage.

Why stale data becomes the design constraint

Caching database reads is easy; preserving correctness is harder. TypeORM’s native cache behavior is time-based, which is acceptable for some workloads but not for request flows that may read immediately after a write. The article’s approach avoids TTL-based staleness by clearing the entire request cache on save, update, and delete operations. That turns the cache into a read-optimisation layer with explicit invalidation semantics rather than a general-purpose data store. For identity-heavy workflows, this distinction matters because entitlement, membership, and policy data can change mid-request and must not be served from an old snapshot.

Practical implication: treat invalidation as part of the cache design, not as an optional add-on after performance tuning.

How instrumentation proved the cache was actually helping

The team measured query reduction with PostgreSQL’s pg_stat_statements extension rather than relying only on in-app hit counts. That matters because request-local caches can look busy inside application logs while the real question is whether the database saw fewer executions. By resetting stats, exercising the same pages with the cache on and off, and comparing query counts, they could quantify the difference directly at the database layer. This is the right measurement model for request-scoped optimisation: measure the backend workload, not just the cache activity.

Practical implication: validate request-scoped optimisations with database-side telemetry so you can prove they reduce actual load.

NHI Mgmt Group analysis

Request-scoped caching is a workload-shaping control, not a data-governance control. The article shows a common backend pattern: many helpers ask the same question about the same state during one request. That is not an access-control failure, but it is a performance and consistency pressure point that identity-aware platforms often underestimate. The practitioner lesson is to design for repeated state access without turning the application into a shared-state cache machine.

Cache scope is the real boundary, and request scope is usually the only safe default. A broader cache would have improved read reuse but increased the chance of stale identity or entitlement data escaping its intended context. By keeping the cache local to the request, the team preserved the same trust boundary that governs the HTTP transaction. The broader point is that state reuse should follow the same boundary as the decision it supports.

Instrumentation is part of the control, not a postscript. The article’s use of database-side query statistics is the kind of evidence practitioners need before they generalise a pattern across services. Without that measurement, teams tend to argue from intuition about cache hit rates rather than from actual load reduction. The practical implication is to validate optimisation at the layer where cost is paid, not only where convenience is observed.

Query amplification deserves a named governance lens: identity lookup duplication. Many enterprise applications re-read the same memberships, entitlements, and settings multiple times in one transaction. That pattern is easy to ignore until scale makes it expensive. The governance implication is that repeated identity-state reads are a design smell when they are not intentionally scoped, measured, and invalidated.

The right performance gain is the one that does not weaken freshness guarantees. This article is valuable because it does not trade correctness for speed. The cache only exists inside the request and is explicitly cleared on writes, which keeps the optimisation defensible in environments where state can change mid-flow. Practitioners should treat that combination as the baseline for any cache that touches security-relevant or identity-relevant data.

What this signals

Identity lookup duplication is a hidden performance tax. When the same memberships, entitlements, or environment settings are read repeatedly inside one request, the right optimisation is to remove redundant lookups without widening the trust boundary. That keeps application code fast while preserving the freshness properties that identity decisions depend on.

Request-scoped optimisation is safer than application-wide caching for security-relevant data. A cache that lives only for the lifetime of one HTTP request avoids the hardest class of stale-state problems while still reducing database load. For practitioners, the design question is not whether to cache, but whether the cache boundary matches the decision boundary.

For practitioners

• Define the request boundary first Place any read cache inside request-local storage so repeated helper calls can reuse the same result without creating a shared cross-request state layer.
• Invalidate on every write path Clear the cache immediately after save, update, or delete operations so a request never serves state that changed earlier in the same lifecycle.
• Measure at the database layer Use PostgreSQL query statistics or equivalent backend telemetry to compare real query counts before and after the cache is enabled.
• Limit caching to repeated read paths Target queries that recur through shared service layers, entitlement checks, or membership lookups instead of trying to cache every query indiscriminately.

Key takeaways

• Repeated database reads inside a single request can create avoidable load even when application code is already well structured.
• Request-scoped caching works because it preserves request boundaries while removing duplicate lookups, but only if writes clear the cache immediately.
• The strongest version of this pattern is measured at the database layer, so teams can prove that the optimisation reduces actual query volume.

Key terms

• Request-Scoped Cache: A request-scoped cache stores computed results only for the duration of one application request. It reduces repeated work inside that path while preserving isolation between users and sessions. In identity-heavy services, it is useful only when invalidation on writes is immediate and the cached data cannot outlive the request.
• Continuation-Local Storage: Continuation-local storage is a technique for carrying state through asynchronous call chains without passing it explicitly through every function. It lets a service keep request-specific data available across helpers, promises, and middleware. In modern application stacks, it is often used to attach bounded context to one execution path.
• Query Result Cache: A query result cache stores the output of a database query so repeated executions can return the same result without requerying the database. In practice, the control is only safe when scope and invalidation are aligned with the data's freshness requirements.
• Request-Scope Invalidation: Request-scope invalidation removes cached state when the underlying data changes during the same request. For identity- or entitlement-relevant data, it is the mechanism that prevents a performance optimisation from serving outdated authorization context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.