Πώς κάνετε cache για να μειώσετε το DB load σε εκατομμύρια req/min;

Question

IT Interview Practice · Accepted Answer

Βάλτε ένα **cache-aside** layer (Redis/Memcached) μπροστά από τη βάση ώστε τα reads να χτυπάνε τη μνήμη, δώστε στα entries ένα **TTL** και κάντε **invalidate στο write**, προσθέστε **stampede protection** ώστε ένα cold key να μην μπορεί να απελευθερώσει ένα thundering herd στη βάση, και απλώστε τα **hot keys** σε replicas ώστε ένα δημοφιλές key να μη λιώνει ένα μοναδικό node.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

Στο **cache-aside** η app ελέγχει το cache· σε ένα miss διαβάζει τη βάση και γεμίζει το cache η ίδια. Στο **read-through** η βιβλιοθήκη του cache το κάνει για εσάς. Είτε έτσι είτε αλλιώς ο στόχος είναι ο ίδιος: μετατρέψτε ένα 5ms DB query σε ένα 0.2ms memory lookup, ώστε ένα cache με 95% hit rate να κόβει το DB read traffic **20×**. Σε εκατομμύρια req/min η βάση απλώς δεν μπορεί να σερβίρει κάθε read — το cache είναι που κάνει τους αριθμούς να δουλεύουν.

## TTL + invalidation

Δύο τρόποι να κρατήσετε το cache φρέσκο, και συνήθως χρειάζεστε και τους δύο. Το **TTL** φράζει το staleness — ένα entry λήγει μετά από N δευτερόλεπτα ώστε τα λάθος δεδομένα να αυτο-θεραπεύονται. Το **explicit invalidation** διαγράφει/ενημερώνει το key στο write για ορθότητα που δεν μπορεί να περιμένει το TTL. Το κλασικό bug είναι το caching χωρίς invalidation και το σερβίρισμα stale δεδομένων για λεπτά· το πιο λεπτό είναι το invalidating *και* το setting στο ίδιο write, που κάνει race.

## Stampede protection & hot keys

- **Stampede (thundering herd):** όταν ένα hot key λήγει, χιλιάδες ταυτόχρονα misses χτυπάνε όλα τη βάση μαζί και μπορούν να τη ρίξουν. Διορθώστε με ένα **per-key lock/single-flight** (μόνο ένα request ξανα-υπολογίζει, τα υπόλοιπα περιμένουν) ή **early/probabilistic refresh** πριν τη λήξη.
- **Hot keys:** ένα key (το προφίλ ενός celebrity) μπορεί να κορεσίσει τη CPU/network ενός μοναδικού Redis node. Απλώστε το — κάντε replicate το key σε nodes, ή προσθέστε ένα μικρό local in-process cache μπροστά από το Redis για τα πιο hot items.

## Οπτική συνέντευξης

Ο συνεντευκτής θέλει να σας δει να σκέφτεστε πέρα από το "πρόσθεσε Redis". Καλό: cache-aside με TTL. Εξαιρετικό: κατονομάζετε **stampede protection, invalidation strategy, hot-key handling, και τι συμβαίνει σε ένα cache outage**. Η παγίδα είναι να θεωρείτε ότι το cache είναι πάντα up — αν το Redis πεθάνει και κάθε miss πέσει στη βάση, παίρνετε μια **cache-avalanche** που ρίχνει και τη βάση.

## Trade-offs & τρόποι αποτυχίας

- **Staleness vs load:** μικρό TTL = φρέσκο αλλά περισσότερα misses· μεγάλο TTL = λιγότερα misses αλλά πιο stale. Ρυθμίστε ανά data.
- **Cache avalanche:** πολλά keys που λήγουν μαζί (ίδιο TTL) προκαλούν load spike — κάντε **jitter** τα TTLs.
- **Consistency:** cache και βάση μπορούν να αποκλίνουν· για money-critical reads, διαβάστε τη βάση ή χρησιμοποιήστε write-through.
- **Memory eviction:** υπό πίεση το Redis κάνει evict κατά policy (LRU/LFU)· μια λάθος policy σιωπηλά πετάει το hot set σας.

Cache-aside vs read-through

TTL + invalidation

Stampede protection & hot keys

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις