Cilat strategji cache-imi përmirësojnë performancën e një Node API?

Question

Accepted Answer

**Cache-imi** ruan rezultatet e operacioneve të shtrenjta (pyetje në BD, llogaritje, thirrje në API të jashtme) në mënyrë që kërkesat e përsëritura të shërbehen shpejt pa përsëritur punën. Është një nga optimizueset me ndikim më të lartë për performancën e një API.

## Cache-imi në memorie (më i shpejtë, instancë e vetme)

```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;
}
```

I thjeshtë dhe jashtëzakonisht i shpejtë, por cache-i është **për-proces** (nuk ndahet në instanca të shumta) dhe humbet në ristartime. I mirë për të dhëna të vogla dhe të nxehta — por ka nevojë për evaksion (përdor një cache LRU si `lru-cache`) për të kufizuar memorien.

## Cache-imi i shpërndarë me Redis (i ndajnë, i zgjerueshëm)

```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** është standardi për cache-imin në instanca të shumta të serverit — një burim i ndajnë, i shpejtë që përjeton restarte dhe zgjerohet me aplikacionin tuaj. **TTL** (time-to-live) skadon hyrjet automatikisht në mënyrë që të dhënat të mos bëhen të vjetra përgjithmonë.

## Cache-imi HTTP (leje klientëve/CDN-ve të bëjnë cache)

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

Headera të cache-it HTTP i caktojnë cache-imin në shfletues dhe CDN-e tërësisht — cache-i më i shpejtë është kërkesa që kurrë nuk arrin në serverin tuaj.

## Pjesa e vështirë: znevalidimi i cache-it

```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
}
```

Sfida më e madhe e cache-imit është **znevalidimi** — sigurimi që përditësimet pastrojnë/rifreskojnë hyrjet e ndikuara të cache-it në mënyrë që përdoruesit të mos shohin të dhëna të vjetra. Strategjit: TTL (pranoni pak qëndrueshmëri), write-through (përditëso cache-in në shkrimin), ose fshirje eksplicite në mutacion.

## Çfarë të bëjë cache dhe jo

```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
```

## Pse ka rëndësi

Cache-imi redukton dramatikisht latencën dhe ngarkesën e bazës së të dhënave/jashtme, shpesh ndryshimi midis një API të ngadaltë dhe një të shpejtë, të zgjerueshëm.

Dija e shtresave — në memorie (më e shpejtë, për-instancë, e kufizuar me LRU), Redis (i ndarë në instanca), dhe cache-imi HTTP/CDN (cakto tërësisht) — të lejon të zgjedhësh strategjinë e duhur.

Dhe kuptimi i vështirësisë qendrore të cache-imit, **znevalidimi** (përmes TTL ose pastrimit eksplicit në shkrimet), është ajo që parandalon dështimin klasik të kompromisit të shërbimit të përdoruesve të dhëna të vjetra.

Cache-imi efektiv është një nga mjetet më të ndikueshme për performancën dhe skalueshmërinë e API-t.