Hvordan cacher du for å kutte DB-belastning ved millioner req/min?

Question

IT Interview Practice · Accepted Answer

Sett et **cache-aside**-lag (Redis/Memcached) foran DB-en slik at lesninger treffer minne, gi oppføringer en **TTL** og **invalider ved write**, legg til **stampede-beskyttelse** slik at en cold key ikke kan slippe løs en thundering herd på DB-en, og spre **hot keys** over replicas slik at én populær key ikke smelter en enkelt node.

```text
                 ┌── hit ──▶ returner verdi
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB-lesning ─▶ set(TTL) ─▶ returner
                              │
                    (kun ÉN miss populerer; andre venter)
DB writes ──▶ invalider/oppdater key
```

## Cache-aside vs read-through

I **cache-aside** sjekker appen cachen; ved en miss leser den DB-en og populerer cachen selv. I **read-through** gjør cache-biblioteket det for deg. Uansett er målet det samme: gjøre en 5ms DB-spørring til et 0.2ms minne-oppslag, slik at en cache med 95% hit rate kutter DB-lesetrafikk **20×**. Ved millioner req/min kan DB-en rett og slett ikke betjene hver lesning — cachen er det som får tallene til å gå opp.

## TTL + invalidering

To måter å holde cachen fersk, og du trenger vanligvis begge. **TTL** avgrenser staleness — en oppføring utløper etter N sekunder slik at feil data self-healer. **Eksplisitt invalidering** sletter/oppdaterer key-en ved write for korrekthet som ikke kan vente på TTL. Den klassiske bugen er å cache uten invalidering og servere stale data i minutter; den mer subtile er å invalidere *og* sette i samme write, som racer.

## Stampede-beskyttelse og hot keys

- **Stampede (thundering herd):** når en hot key utløper, treffer tusenvis av samtidige misses DB-en samtidig og kan velte den. Fiks med en **per-key lock/single-flight** (kun én request rekomputerer, andre venter) eller **tidlig/probabilistisk refresh** før utløp.
- **Hot keys:** én key (en celebrity-profil) kan mette en enkelt Redis-nodes CPU/nettverk. Spre den — replikér key-en over noder, eller legg til en liten lokal in-process cache foran Redis for de heteste elementene.

## Intervjuperspektiv

Intervjueren vil se at du tenker forbi "legg til Redis". Bra: cache-aside med TTL. Utmerket: du navngir **stampede-beskyttelse, invalideringsstrategi, hot-key-håndtering, og hva som skjer ved et cache-utfall**. Fellen er å anta at cachen alltid er oppe — hvis Redis dør og hver miss faller gjennom til DB-en, får du en **cache-avalanche** som tar DB-en ned også.

## Avveininger og feilmoduser

- **Staleness vs belastning:** kort TTL = fersk men flere misses; lang TTL = færre misses men stalere. Juster per data.
- **Cache avalanche:** mange keys utløper sammen (samme TTL) forårsaker en belastnings-spike — **jitter** TTL-ene.
- **Konsistens:** cache og DB kan divergere; for penge-kritiske lesninger, les DB-en eller bruk write-through.
- **Minne-eviction:** under press evicter Redis etter policy (LRU/LFU); en feil policy dropper stille ditt hot set.

Cache-aside vs read-through

TTL + invalidering

Stampede-beskyttelse og hot keys

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål