NestJS fornece um módulo de caching integrado (@nestjs/cache-manager) com uma API unificada que funciona em diferentes stores — em memória por padrão, ou Redis para caching distribuído entre múltiplas instâncias. Caching melhora dramaticamente a performance evitando trabalho caro repetido.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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
}
}
O CacheInterceptor armazena em cache respostas de endpoints GET automaticamente (chaveadas por URL) e serve resultados em cache em requisições repetidas — a forma mais simples de cachear endpoints com leitura intensiva.
@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;
}
}
Injetar CACHE_MANAGER oferece controle total — o padrão get-or-fetch (verificar cache, recorrer à fonte, armazenar resultado) para cachear operações específicas caras.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
A mesma API, apoiada por Redis, fornece um cache compartilhado entre todas as instâncias da aplicação — essencial ao rodar múltiplas instâncias (um cache em memória não é compartilhado entre elas).
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 é uma das otimizações de performance de maior impacto para aplicações back-end, e o módulo de caching integrado do NestJS torna isso limpo e consistente.
Entender isso é importante porque APIs com leitura intensiva se beneficiam enormemente do caching de operações caras (queries de banco de dados, chamadas a APIs externas, computações) — reduzindo drasticamente latência e carga.
NestJS oferece tanto auto-caching simples (o CacheInterceptor para endpoints GET) quanto controle fino manual (o padrão get-or-fetch do CACHE_MANAGER para operações específicas).
",, um ponto importante é que a API unificada funciona com diferentes stores, então o mesmo código pode usar caching em memória (rápido, instância única) ou Redis (cache compartilhado entre múltiplas instâncias) — e saber que um cache em memória não é compartilhado ao escalar horizontalmente (requerendo Redis para caching distribuído) é um ponto arquitetural importante.
Igualmente importante é entender a dificuldade central do caching — invalidação (limpar ou atualizar o cache quando dados mudam, via TTL ou exclusão explícita, para evitar servir dados obsoletos) — já que acertar isso errado é a falha clássica de caching.
Saber como e quando aplicar caching, escolher o store certo para o deployment, e lidar com invalidação corretamente é conhecimento valioso de nível sênior para construir serviços NestJS rápidos e escaláveis.