Koje strategije cachiranja poboljšavaju performanse Node API-ja?

Question

Accepted Answer

**Caching** sprema rezultate skupih operacija (DB upiti, izračuni, pozivi vanjskih API-ja) kako bi se ponovljeni zahtjevi mogli brzo poslužiti bez ponovnog rada. To je jedna od cacheacija s najvećim utjecajem na optimizaciju performansi API-ja.

## In-memory caching (najbrži, jednostavna instanca)

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

Jednostavan i izuzetno brz, ali je cache **po procesu** (ne dijeli se između instanci) i gubi se nakon restarta. Dobar za male, često korištene podatke — ali trebate eviction (koristite LRU cache poput `lru-cache`) kako bi ograničili memoriju.

## Distribuirani caching s Redison (zajednički, skalabilan)

```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** je standard za caching na više serverskih instanci — zajedničko, brzo spremište koje preživi restarte i skalira se s vašom aplikacijom. **TTL** (time-to-live) automatski briše stavke tako da podaci ne postanu zastarjeli zauvijek.

## HTTP caching (neka klijenti/CDN-ovi cachiraju)

```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 headeri prebacuju caching na preglednike i CDN-ove u potpunosti — najbrži cache je zahtjev koji nikada ne dosegne vaš server.

## Teški dio: invalidacija cachea

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

Najveći challenge cachiranja je **invalidacija** — osiguravajući da ažuriranja očiste/osvježe pogođene cache stavke kako korisnici ne bi vidjeli zastarjele podatke. Strategije: TTL (prihvatite kratku zastarjelost), write-through (ažurirajte cache pri pisanju), ili eksplicitno brisanje pri mutaciji.

## Što cachirati (i što ne)

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

## Zašto je važno

Caching dramatično smanjuje latenciju i opterećenje baze podataka/vanjskih resursa, često je to razlika između sporog API-ja i brzog, skalabilnog.

Znajući slojeve — in-memory (najbrži, po instanci, ograničen s LRU), Redis (zajedničko kroz instance), i HTTP/CDN caching (potpuno prebacivanje) — možete odabrati pravu strategiju.

I razumijevanje centralnog problema cachiranja, **invalidacije** (putem TTL-a ili eksplicitnog čišćenja pri pisanju), je ono što sprječava klasičan neuspjeh kompromisa posluženih zastarjelih podataka korisnicima.

Efikasno caching je jedan od najprimamljivijih alata za performanse API-ja i skalabilnost.