Ποιες στρατηγικές caching βελτιώνουν την απόδοση ενός Node API;

Question

Accepted Answer

**Caching** αποθηκεύει τα αποτελέσματα δαπανηρών λειτουργιών (ερωτήματα DB, υπολογισμοί, κλήσεις εξωτερικών API) ώστε επαναλαμβανόμενα αιτήματα να μπορούν να εξυπηρετηθούν γρήγορα χωρίς να επαναληφθεί η δουλειά. Είναι μία από τις βελτιστοποιήσεις απόδοσης με τη μεγαλύτερη επίδραση για ένα API.

## In-memory caching (ταχύτατο, μεμονωμένη instance)

```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 είναι **ανά διαδικασία** (δεν είναι κοινό σε όλες τις instances) και χάνεται στην επανεκκίνηση. Κατάλληλο για μικρά, ζεστά δεδομένα — αλλά χρειάζεται eviction (χρησιμοποιήστε ένα LRU cache όπως `lru-cache`) για να περιορίσετε τη μνήμη.

## Distributed caching με 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 σε πολλαπλές instances διακομιστή — ένα κοινό, γρήγορο αποθετήριο που επιζεί στις επανεκκινήσεις και κλιμακώνεται με την εφαρμογή σας. Το **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 σε browsers και 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
}
```

Η μεγαλύτερη πρόκληση του caching είναι η **invalidation** — διασφάλιση ότι οι ενημερώσεις διαγράφουν/ανανεώνουν τις σχετικές καταχωρήσεις cache ώστε οι χρήστες να μη δουν παλιά δεδομένα. Στρατηγικές: TTL (αποδεκτή σύντομη παλαιότητα), write-through (ενημέρωση cache κατά την εγγραφή), ή ρητή διαγραφή κατά τη μετάλλαξη.

## Τι να κάνετε 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 μειώνει δραματικά την καθυστέρηση και το φορτίο της βάσης δεδομένων/εξωτερικών υπηρεσιών, συχνά η διαφορά μεταξύ ενός αργού API και ενός γρήγορου, κλιμακώσιμου.

Γνώση των επιπέδων — in-memory (ταχύτατο, ανά instance, περιορισμένο με LRU), Redis (κοινό σε όλες τις instances), και HTTP/CDN caching (μεταφορά εξ ολοκλήρου) — σας επιτρέπει να επιλέξετε τη σωστή στρατηγική.

Και η κατανόηση της κεντρικής δυσκολίας του caching, **invalidation** (μέσω TTL ή ρητής διαγραφής κατά τις εγγραφές), είναι αυτό που αποτρέπει την κλασική αποτυχία trade-off της εξυπηρέτησης παλιών δεδομένων στους χρήστες.

Το αποτελεσματικό caching είναι ένα από τα πιο σημαντικά εργαλεία για την απόδοση και κλιμάκωση του API.