Node API ਦੀ ਕਾਰਗਿਰੀ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਕਿਹੜੀਆਂ caching ਰਣਨੀਤਿਆਂ ਹਨ?

Question

Accepted Answer

**Caching** ਮਹਿੰਗੇ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ (DB ਕਿਊਰੀਜ, ਗਣਨਾਵਾਂ, ਬਾਹਰੀ API ਕਾਲ) ਤਾਂ ਜੋ ਦੁਬਾਰਾ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਦਿੱਤੀਆਂ ਜਾ ਸਕਣ ਬਿਨਾ ਕੰਮ ਨੂੰ ਦੁਬਾਰਾ ਨਾ ਕਰਨਾ ਪਵੇ। ਇਹ ਇੱਕ API ਲਈ ਸਭ ਤੋਂ ਵੱਡਾ ਪ੍ਰਭਾਵ ਰੱਖਣ ਵਾਲੀ ਕਾਰਗਿਰੀ ਕਸੌਟੀ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

## In-memory caching (ਸਭ ਤੋਂ ਤੇਜ਼, ਸਿੰਗਲ-ਇਨਸ਼ਟੈਂਸ)

```js
const cache = new Map();

async function getUser(id) {
  if (cache.has(id)) return cache.get(id); // cache HIT — instant
  const user = await db.findUser(id);       // cache MISS — do the work
  cache.set(id, user);
  return user;
}
```

ਸਧਾਰਣ ਅਤੇ ਬਹੁਤ ਤੇਜ਼, ਪਰ cache **ਪ੍ਰਤੀ-ਪ੍ਰਕਿਰਿਆ** ਹੈ (ਇਨਸ਼ਟੈਂਸਾਂ ਵਿੱਚ ਸਾਂਝਾ ਨਹੀਂ) ਅਤੇ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਉੱਤੇ ਗੁਆ ਜਾਂਦਾ ਹੈ। ਛੋਟੇ, ਗਰਮ ਡੇਟਾ ਲਈ ਚੰਗਾ — ਪਰ eviction ਦੀ ਲੋੜ ਹੈ (memory ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ `lru-cache` ਜਿਵੇਂ ਇੱਕ LRU cache ਵਰਤੋ)।

## Distributed caching with Redis (ਸਾਂਝਾ, ਸਕੇਲਬਲ)

```js
import { createClient } from "redis";
const redis = createClient();

async function getUser(id) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);          // hit

const user = await db.findUser(id);
  await redis.setEx(`user:${id}`, 3600, JSON.stringify(user)); // cache for 1h (TTL)
  return user;
}
```

**Redis** ਕਈ ਸਰਵਰ ਇਨਸ਼ਟੈਂਸਾਂ ਵਿੱਚ caching ਲਈ ਮਾਪਦੰਡ ਹੈ — ਇੱਕ ਸਾਂਝਾ, ਤੇਜ਼ ਸਟੋਰ ਜੋ restarts ਨੂੰ ਸਾਹ ਲੈਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਦੇ ਨਾਲ ਸਕੇਲ ਕਰਦਾ ਹੈ। **TTL** (time-to-live) ਆਪਣੇ ਆਪ ਨੂੰ ਐਂਟਰੀਜ਼ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਡੇਟਾ ਹਮੇਸ਼ਾ ਲਈ ਪੁਰਾਣਾ ਨਾ ਹੋ ਜਾਵੇ।

## HTTP caching (ਕਲਾਇੰਟਾਂ/CDNs ਨੂੰ cache ਕਰਨ ਦਿਓ)

```js
res.set("Cache-Control", "public, max-age=3600"); // browsers/CDN cache for 1h
res.set("ETag", hash);                            // conditional requests (304 Not Modified)
```

HTTP cache headers caching ਨੂੰ ਬ੍ਰਾਊਜ਼ਰਾਂ ਅਤੇ CDNs ਤੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਫਲੋਡ ਕਰਦੇ ਹਨ — ਸਭ ਤੋਂ ਤੇਜ਼ cache ਬੇਨਤੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਰਵਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ।

## ਮੁਸ਼ਕਲ ਹਿੱਸਾ: cache invalidation

```js
// when data changes, the cache must be updated or cleared, or users see stale data
async function updateUser(id, data) {
  await db.updateUser(id, data);
  await redis.del(`user:${id}`); // INVALIDATE — next read repopulates with fresh data
}
```

Sabse bada caching challenge **invalidation** ਹੈ — ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ updates متاثر شده cache entries ਨੂੰ ਸਾਫ/ਤਾਜ਼ਾ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਉਪਯੋਗਕਰਤਾ ਪੁਰਾਣਾ ਡੇਟਾ ਨਾ ਦੇਖਣ। ਰਣਨੀਤਿਆਂ: TTL (ਸੰਖੇਪ ਸਟੇਲਨੈਸ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ), write-through (write ਉੱਤੇ cache ਨੂੰ ਅਪਡੇਟ ਕਰੋ), ਜਾਂ mutation ਉੱਤੇ ਸਪਸ਼ਟ ਹਟਾਓ।

## ਕੀ cache ਕਰਨਾ ਹੈ (ਅਤੇ ਨਹੀਂ)

```text
✓ Read-heavy, infrequently-changing data (config, product catalogs, user profiles)
✓ Expensive computations, external API responses
✗ Highly dynamic/personalized or rapidly-changing data (or use very short TTLs)
✗ Sensitive data without care for who can read the cache
```

## ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

Caching ਨਾਟਕੀ ਢੰਗ ਨਾਲ latency ਅਤੇ database/external load ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ, ਅਕਸਰ ਇੱਕ ਸਸਤੇ API ਅਤੇ ਇੱਕ ਤੇਜ਼, scalable API ਵਿਚਕਾਰ ਫਰਕ।

Slayers ਨੂੰ ਜਾਣਨਾ — in-memory (ਸਭ ਤੋਂ ਤੇਜ਼, per-instance, LRU ਦੇ ਨਾਲ ਬਾਊਂਡ), Redis (instances ਵਿੱਚ ਸਾਂਝਾ), ਅਤੇ HTTP/CDN caching (ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਫਲੋਡ) — ਤੁਹਾਨੂੰ ਸਹੀ ਰਣਨੀਤੀ ਚੁਣਨ ਦਿੰਦਾ ਹੈ।

Aur caching ਦੀ ਕੇਂਦਰੀ ਮੁਸ਼ਕਲ ਨੂੰ ਸਮਝਣਾ, **invalidation** (TTL ਜਾਂ writes ਉੱਤੇ ਸਪਸ਼ਟ ਸਫ਼ਾਈ ਦੇ ਰਾਹੀਂ), ਉਸ ਕਲਾਸਿਕ ਟਰੇਡ-ਆਫ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਪਯੋਗਕਰਤਾ ਪੁਰਾਣਾ ਡੇਟਾ ਦੇਖਦੇ ਹਨ।

Effective caching API performance ਅਤੇ scalability ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਟੂਲਸ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।