Caching w NestJS - Jak efektywnie przyspieszyć działanie swojej aplikacji

NestJS ma wbudowany CacheModule oparty o pakiet cache-manager: instalujesz @nestjs/cache-manager, rejestrujesz CacheModule.register() w module aplikacji i dekorujesz endpointy przez @UseInterceptors(CacheInterceptor). Domyślnie pod spodem działa cache w pamięci procesu (LRU), a w produkcji zwykle Redis przez odpowiedni adapter. Abstrakcja jest cienka — łatwo zejść niżej, gdy potrzebujesz pełnej kontroli nad kluczami i czasem życia wpisów.

Cache w pamięci wystarcza dla pojedynczej instancji aplikacji, środowisk deweloperskich i prototypów: zero infrastruktury i najszybszy dostęp, ale dane znikają przy restarcie, a każda instancja ma własny, rozjeżdżający się cache. Redis to wybór produkcyjny przy wielu instancjach Node.js (load balancing, Kubernetes): wspólny, trwały cache plus dodatkowe możliwości — pub/sub, sorted sets. Praktyczna reguła: dev i staging na pamięci, produkcja z więcej niż jedną instancją — zawsze Redis.

TTL — każdy wpis wygasa po zadanym czasie; najprostsza i wystarczająca dla danych zmieniających się okresowo. Ręczne unieważnianie — po aktualizacji zasobu wywołujesz cacheManager.del(klucz); właściwe dla danych zmienianych rzadko, ale krytycznie (np. uprawnienia). Tagowanie — grupowanie powiązanych wpisów i czyszczenie całego taga naraz. Pub/sub — po zmianie danych publikujesz zdarzenie w Redisie, a wszystkie instancje czyszczą swoje lokalne kopie. Unieważnianie to najtrudniejsza część cache'owania — projektuj ją świadomie.

Wstrzyknij menedżera przez @Inject(CACHE_MANAGER) i używaj bezpośrednio get/set/del. Dla niestandardowych kluczy rozszerz CacheInterceptor i nadpisz trackBy() — np. cache per użytkownik. Dekoratory @CacheKey i @CacheTTL konfigurują pojedyncze endpointy. Cache warunkowy realizuje się nadpisując logikę interceptora — klasycznie: tylko żądania GET, tylko dla wybranych ról.

Cache stampede: gdy popularny wpis wygasa, lawina żądań uderza w bazę jednocześnie — ratunkiem są blokady (RedLock) albo wzorzec stale-while-revalidate. Zanieczyszczenie cache rzadko używanymi danymi wypierającymi popularne — pomaga eviction LRU. Niespójność, gdy cache serwuje stare dane po aktualizacji — to kwestia dyscypliny unieważniania. Wycieki pamięci przy wpisach bez TTL oraz kolizje kluczy, gdy dwa różne zasoby dostają ten sam klucz — konwencja nazewnicza kluczy jest obowiązkowa.