Notifications
Clear all
Topic starter
08/06/2026 5:07 pm
TL;DR: A request-scoped query-cache layer in a NestJS plus TypeORM backend reduced duplicate database reads by about 30% with no query rewrites, according to WorkOS, but only by combining context-local storage with aggressive invalidation on writes. The lesson for practitioners is that performance gains are real when cache scope, staleness, and instrumentation are all designed together, not bolted on.
NHIMG editorial — based on content published by WorkOS: Query caching using Nest.js and Typeorm
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
A: Use request-scoped caching, not process-wide caching, so reuse is limited to one execution context.
A: Because each helper or service can ask the same question again, even when the answer has not changed within that request.
Q: How do you know whether query caching is actually reducing load?
A: Measure database executions directly, preferably with server-side telemetry such as pg_stat_statements, and compare the same user journey with caching enabled and disabled.
Practitioner guidance
- Map repeated identity reads within a single request Trace where the same user, team, entitlement, or settings query appears across helper layers, and quantify the duplication before changing architecture.
- Scope caches to the execution context Use context-local storage or an equivalent request-bound mechanism so cached data disappears when the request ends.
- Invalidate on every mutating write Clear the entire request cache after save, update, or delete operations if the cached values can influence access decisions or user-visible state.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves at the architecture level:
- The TypeORM cache-provider wiring needed to enable query reuse without rewriting every query builder
- The NestJS CLS setup pattern that keeps cache state bound to a single HTTP request
- The repository overrides used to clear cached results on save, update, and delete operations
- The pg_stat_statements testing method used to verify the 30% drop in repeated database reads
👉 Read WorkOS's query caching implementation for NestJS and TypeORM →
Request-scoped query caching in NestJS and TypeORM: what changes?
Explore further
08/06/2026 7:08 pm
Repeated-read elimination is an identity governance pattern, not just an application performance trick. Any IAM or entitlement workflow that asks the same question many times inside one request creates avoidable database load and hidden complexity. The deeper point is that governance systems often pay for the same lookup repeatedly because their service layers are decomposed but not context-aware. Practitioners should treat request-scoped reuse as a control boundary for stateful checks, not as a backend optimisation alone.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 44% of developers are reported to follow security best practices for secrets management, which means behaviour gaps often outlast platform intentions.
A question worth separating out:
Q: What is the difference between request-scoped caching and a shared application cache?
A: Request-scoped caching lives only for one HTTP request and cannot leak across users or sessions. A shared application cache persists longer, which can improve reuse but raises correctness and isolation risks when the underlying data changes. For identity-adjacent data, request scope is the safer default.
👉 Read our full editorial: Request-scoped query caching cuts duplicate database reads by 30%
