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 は自動的に GET エンドポイントのレスポンスをキャッシュし（URLをキーとして）、リピートリクエストではキャッシュ結果を返します。これは読み取り集約的なエンドポイントをキャッシュする最も簡単な方法です。
@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.
キャッシングはバックエンド・アプリケーションにおいて最も高い影響を与えるパフォーマンス最適化の一つであり、NestJSの組み込みキャッシングモジュールは、これをクリーンで一貫性のある方法で実現します。
読み取り集約的なAPIが高コスト処理（データベースクエリ、外部API呼び出し、計算）をキャッシングすることで大きなメリットを得られるため、理解することは重要です。レイテンシーと負荷を劇的に削減できます。
NestJSは単純な自動キャッシング（CacheInterceptorを使ったGETエンドポイント用）と細粒度なマニュアル制御（特定の処理用のCACHE_MANAGER get-or-fetchパターン）の両方を提供しています。
重要な点として、統一されたAPIが異なるストアで動作するため、同じコードがインメモリキャッシング（高速、単一インスタンス）またはRedis（複数インスタンス間の共有キャッシュ）を使用できます。水平スケーリング時にインメモリキャッシュが共有されないこと（分散キャッシング向けにRedisが必要）を理解することは、重要なアーキテクチャ的な観点です。
同等に重要なのは、キャッシングの中心的な難しさ—無効化（データ変更時にキャッシュをクリアまたは更新する、TTLまたは明示的削除を通じてスターデータの提供を回避）—を理解することです。これを誤ると、典型的なキャッシング失敗につながります。
どうやって、いつキャッシングを適用するか、デプロイ向けに正しいストアを選択する方法、そして無効化を正しく処理する方法を知ることは、高速でスケーラブルなNestJSサービス構築のためのシニアレベルの貴重な知識です。