NestJS bietet ein integriertes Caching-Modul (@nestjs/cache-manager) mit einer einheitlichen API, die über verschiedene Speicher funktioniert — standardmäßig im Speicher oder Redis für verteiltes Caching über mehrere Instanzen hinweg. Caching verbessert die Performance dramatisch, indem wiederholte teure Operationen vermieden werden.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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
}
}
Der CacheInterceptor speichert automatisch GET-Endpunkt-Antworten (Schlüssel nach URL) und liefert beim wiederholten Abruf gecachte Ergebnisse — die einfachste Möglichkeit, leseintensive Endpunkte zu cachen.
@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;
}
}
Das Injizieren von CACHE_MANAGER gibt volle Kontrolle — das Get-or-Fetch-Muster (Cache prüfen, auf Quelle zurückgreifen, Ergebnis speichern) zum Cachen spezifischer teurer Operationen.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Dieselbe API, unterstützt durch Redis, bietet einen gemeinsamen Cache über alle App-Instanzen hinweg — essentiell beim Betrieb mehrerer Instanzen (ein In-Memory-Cache wird nicht zwischen ihnen geteilt).
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 ist eine der Optimierungen mit größtem Effekt auf die Performance von Backend-Anwendungen, und das integrierte Caching-Modul von NestJS macht es sauber und konsistent.
Das Verstehen ist wichtig, weil leseintensive APIs enorm von Caching teurer Operationen (Datenbankabfragen, externe API-Aufrufe, Berechnungen) profitieren — Latenz und Last werden dramatisch reduziert.
NestJS bietet sowohl einfaches automatisches Caching (der CacheInterceptor für GET-Endpunkte) als auch granulare manuelle Kontrolle (das CACHE_MANAGER Get-or-Fetch-Muster für spezifische Operationen).
Wichtig ist, dass die einheitliche API mit verschiedenen Speichern funktioniert, sodass derselbe Code In-Memory-Caching (schnell, einzelne Instanz) oder Redis (gemeinsamer Cache über mehrere Instanzen) nutzen kann — und zu wissen, dass ein In-Memory-Cache nicht geteilt wird beim horizontalen Skalieren (Redis für verteiltes Caching erforderlich) ist ein wichtiger architektonischer Punkt.
Gleich wichtig ist das Verständnis der zentralen Schwierigkeit des Cachings — Invalidierung (Cache leeren oder aktualisieren, wenn sich Daten ändern, via TTL oder explizites Löschen, um veraltete Daten zu vermeiden) — denn hier falsch zu liegen ist der klassische Cache-Fehler.
Zu wissen, wie und wann man Caching anwendet, den richtigen Speicher für die Bereitstellung wählt und die Invalidierung korrekt handhabt, ist wertvolles Senior-Level-Wissen zum Bau schneller, skalierbarer NestJS-Services.