NestJS предоставляет встроенный модуль кеширования (@nestjs/cache-manager) с единообразным API, работающим с различными хранилищами — по умолчанию в памяти или Redis для распределённого кеширования на нескольких экземплярах. Кеширование существенно улучшает производительность, избегая повторного выполнения дорогостоящих операций.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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
}
}
CacheInterceptor автоматически кеширует ответы endpoint'ов GET (с ключом по URL) и возвращает кешированные результаты при повторных запросах — самый простой способ кеширования endpoint'ов с большим количеством чтений.
@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;
}
}
Инъекция CACHE_MANAGER даёт полный контроль — паттерн get-or-fetch (проверка кеша, обращение к источнику при необходимости, сохранение результата) для кеширования конкретных дорогостоящих операций.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Тот же API, поддержанный Redis, обеспечивает общий кеш для всех экземпляров приложения — необходимо при запуске нескольких экземпляров (кеш в памяти не делится между ними).
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.
Кеширование — одна из высокоэффективных оптимизаций производительности для backend-приложений, и встроенный модуль кеширования NestJS делает это чистым и консистентным.
Понимание этого важно, потому что API с большим количеством операций чтения получают огромную пользу от кеширования дорогостоящих операций (запросы к БД, вызовы внешних API, вычисления) — значительно снижая latency и нагрузку.
NestJS предоставляет как простое автоматическое кеширование (CacheInterceptor для endpoint'ов GET), так и точный ручной контроль (паттерн get-or-fetch CACHE_MANAGER для конкретных операций).
Критически важно понимать, что единообразный API работает с различными хранилищами, поэтому один и тот же код может использовать кеширование в памяти (быстро, один экземпляр) или Redis (общий кеш на несколько экземпляров) — и осознание того, что кеш в памяти не делится при горизонтальном масштабировании (требуя Redis для распределённого кеширования), — важный архитектурный момент.
Единственно важно также понимать центральную сложность кеширования — инвалидацию (очистку или обновление кеша при изменении данных через TTL или явное удаление, чтобы не возвращать устаревшие данные) — так как ошибки здесь приводят к классическим сбоям кеширования.
Знание того, как и когда применять кеширование, выбор подходящего хранилища для развёртывания и правильная обработка инвалидации — это ценные знания уровня старшего разработчика для создания быстрых и масштабируемых сервисов на NestJS.