NestJS provides a built-in caching module (@nestjs/cache-manager) with a unified API that works across stores — in-memory by default, or Redis for distributed caching across multiple instances. Caching dramatically improves performance by avoiding repeated expensive work.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@Controller("products")
@UseInterceptors(CacheInterceptor) // automatically caches GET responses
export class ProductsController {
@Get()
@CacheTTL(30000) // override TTL for this route
findAll() {
return this.productsService.findAll(); // result cached; subsequent GETs are instant
}
}
The CacheInterceptor automatically caches GET endpoint responses (keyed by URL) and serves cached results on repeat requests — the simplest way to cache read-heavy endpoints.
@Injectable()
export class ProductsService {
constructor(@Inject(CACHE_MANAGER) private cache: Cache) {}
async getProduct(id: string) {
const cached = await this.cache.get(`product:${id}`); // check cache first
if (cached) return cached; // cache HIT
const product = await this.db.findProduct(id); // cache MISS — fetch
await this.cache.set(`product:${id}`, product, 3600000); // store (1h TTL)
return product;
}
}
Injecting CACHE_MANAGER gives full control — the get-or-fetch pattern (check cache, fall back to source, store result) for caching specific expensive operations.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
The same API, backed by Redis, gives a shared cache across all app instances — essential when running multiple instances (an in-memory cache isn't shared between them).
async updateProduct(id: string, data) {
await this.db.update(id, data);
await this.cache.del(`product:${id}`); // INVALIDATE on change → avoid stale data
}
The biggest caching challenge: INVALIDATION. When data changes, the cache must be
cleared/updated, or users see stale data. Strategies: TTL (accept brief staleness),
explicit deletion on writes (cache.del), or cache tags.
Caching is one of the highest-impact performance optimizations for back-end applications, and NestJS's built-in caching module makes it clean and consistent.
Understanding it is important because read-heavy APIs benefit enormously from caching expensive operations (database queries, external API calls, computations) — dramatically reducing latency and load.
NestJS offers both simple auto-caching (the CacheInterceptor for GET endpoints) and fine-grained manual control (the CACHE_MANAGER get-or-fetch pattern for specific operations).
Crucially, the unified API works with different stores, so the same code can use in-memory caching (fast, single-instance) or Redis (a shared cache across multiple instances) — and knowing that an in-memory cache isn't shared when scaling horizontally (requiring Redis for distributed caching) is an important architectural point.
Equally important is understanding caching's central difficulty — invalidation (clearing or updating the cache when data changes, via TTL or explicit deletion, to avoid serving stale data) — since getting this wrong is the classic caching failure.
Knowing how and when to apply caching, choosing the right store for the deployment, and handling invalidation correctly is valuable senior-level knowledge for building fast, scalable NestJS services.