NestJS একটি built-in caching module (@nestjs/cache-manager) প্রদান করে যা একটি unified API সহ কাজ করে যা stores জুড়ে কাজ করে — ডিফল্টভাবে in-memory, বা একাধিক instances জুড়ে distributed caching-এর জন্য Redis। Caching পুনরাবৃত্ত ব্যয়বহুল কাজ এড়িয়ে পারফরম্যান্স নাটকীয়ভাবে উন্নত করে।
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 endpoint responses cache করে (URL দ্বারা keyed) এবং পুনরাবৃত্ত অনুরোধে cached results পরিবেশন করে — read-heavy endpoints cache করার সবচেয়ে সহজ উপায়।
@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 inject করা সম্পূর্ণ control দেয় — get-or-fetch প্যাটার্ন (cache check করুন, source-এ fallback করুন, result store করুন) নির্দিষ্ট ব্যয়বহুল operations caching-এর জন্য।
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
একই API, Redis দ্বারা backed, সমস্ত app instances জুড়ে একটি shared cache দেয় — একাধিক instances চালানোর সময় অপরিহার্য (একটি in-memory cache তাদের মধ্যে shared নয়)।
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 ব্যাকএন্ড অ্যাপ্লিকেশনের জন্য সর্বোচ্চ-প্রভাব পারফরম্যান্স অপ্টিমাইজেশনগুলির মধ্যে একটি, এবং NestJS-এর built-in caching module এটিকে পরিচ্ছন্ন এবং সামঞ্জস্যপূর্ণ করে তোলে।
এটি বোঝা গুরুত্বপূর্ণ কারণ read-heavy APIs ব্যয়বহুল operations (database queries, external API calls, computations) caching থেকে অত্যন্ত উপকৃত হয় — latency এবং load নাটকীয়ভাবে হ্রাস করে।
NestJS সহজ auto-caching (GET endpoints-এর জন্য CacheInterceptor) এবং fine-grained manual control (নির্দিষ্ট operations-এর জন্য CACHE_MANAGER get-or-fetch প্যাটার্ন) উভয়ই অফার করে।
গুরুত্বপূর্ণভাবে, unified API বিভিন্ন stores-এর সাথে কাজ করে, তাই একই code in-memory caching (দ্রুত, single-instance) বা Redis (একাধিক instances জুড়ে shared cache) ব্যবহার করতে পারে — এবং জানা যে একটি in-memory cache scaling horizontally-এর সময় shared নয় (distributed caching-এর জন্য Redis প্রয়োজন) একটি গুরুত্বপূর্ণ architectural point।
সমানভাবে গুরুত্বপূর্ণ caching-এর কেন্দ্রীয় অসুবিধা বোঝা — invalidation (data change-এর সময় cache পরিষ্কার বা আপডেট করা, TTL বা explicit deletion-এর মাধ্যমে, stale data serving এড়াতে) — কারণ এটি ভুলভাবে পাওয়া caching failure-এর ক্লাসিক।
কখন এবং কীভাবে caching apply করতে হয়, deployment-এর জন্য সঠিক store বেছে নিতে হয়, এবং invalidation সঠিকভাবে পরিচালনা করতে হয় তা জানা দ্রুত, scalable NestJS services নির্মাণের জন্য মূল্যবান senior-level জ্ঞান।