NestJS proporciona un módulo de caché integrado (@nestjs/cache-manager) con una API unificada que funciona con diferentes almacenes — en memoria por defecto, o Redis para caché distribuido entre múltiples instancias. El caché mejora dramáticamente el rendimiento evitando trabajo costoso 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
}
}
El CacheInterceptor almacena automáticamente en caché las respuestas de endpoints GET (indexadas por URL) y sirve resultados en caché en solicitudes repetidas — la forma más simple de cachear endpoints con muchas lecturas.
@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;
}
}
Inyectar CACHE_MANAGER da control total — el patrón get-or-fetch (verificar caché, recurrir a la fuente, almacenar resultado) para cachear operaciones específicas costosas.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
La misma API, respaldada por Redis, proporciona un caché compartido entre todas las instancias de la app — esencial cuando se ejecutan múltiples instancias (un caché en memoria no se comparte entre ellas).
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.
El caché es una de las optimizaciones de rendimiento con mayor impacto para aplicaciones back-end, y el módulo de caché integrado de NestJS lo hace limpio y consistente.
Es importante entenderlo porque las APIs con muchas lecturas se benefician enormemente de cachear operaciones costosas (consultas a base de datos, llamadas a APIs externas, computaciones) — reduciendo dramáticamente la latencia y la carga.
NestJS ofrece tanto auto-caché simple (el CacheInterceptor para endpoints GET) como control fino manual (el patrón get-or-fetch de CACHE_MANAGER para operaciones específicas).
Crucialmente, la API unificada funciona con diferentes almacenes, por lo que el mismo código puede usar caché en memoria (rápido, una sola instancia) o Redis (un caché compartido entre múltiples instancias) — y saber que un caché en memoria no se comparte al escalar horizontalmente (requiriendo Redis para caché distribuido) es un punto arquitectónico importante.
Igualmente importante es entender la dificultad central del caché — invalidación (limpiar o actualizar el caché cuando los datos cambian, mediante TTL o eliminación explícita, para evitar servir datos anticuados) — ya que hacerlo mal es el fracaso clásico del caché.
Saber cómo y cuándo aplicar caché, elegir el almacén correcto para el despliegue, y manejar la invalidación correctamente es conocimiento valioso de nivel senior para construir servicios NestJS rápidos y escalables.