Hvordan cacher du for at skære DB-belastning ved millioner af req/min?

Question

IT Interview Practice · Accepted Answer

Sæt et **cache-aside**-lag (Redis/Memcached) foran DB'en så reads rammer hukommelse, giv entries en **TTL** og **invalidér ved write**, tilføj **stampede protection** så en cold key ikke kan udløse en thundering herd på DB'en, og spred **hot keys** over replicas så én populær nøgle ikke smelter en enkelt 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

I **cache-aside** tjekker appen cachen; ved en miss læser den DB'en og populerer cachen selv. I **read-through** gør cache-biblioteket det for dig. Uanset hvad er målet det samme: gøre en 5ms DB-forespørgsel til et 0,2ms hukommelsesopslag, så en cache med 95% hit rate skærer DB-read-trafik **20×**. Ved millioner af req/min kan DB'en simpelthen ikke servere hver read — cachen er, hvad der får tallene til at gå op.

## TTL + invalidering

To måder at holde cachen frisk, og du har som regel brug for begge. **TTL** afgrænser forældelse — en entry udløber efter N sekunder, så forkerte data selv-heler. **Eksplicit invalidering** sletter/opdaterer nøglen ved write for korrekthed, der ikke kan vente på TTL. Den klassiske bug er at cache uden invalidering og servere forældede data i minutter; den mere subtile er at invalidere *og* sætte i samme write, hvilket racer.

## Stampede protection & hot keys

- **Stampede (thundering herd):** når en hot key udløber, rammer tusindvis af samtidige misses DB'en på én gang og kan vælte den. Ret med en **per-key lock/single-flight** (kun én request genberegner, andre venter) eller **early/probabilistic refresh** før udløb.
- **Hot keys:** én nøgle (en kendis' profil) kan mætte en enkelt Redis-nodes CPU/netværk. Spred den — replikér nøglen over noder, eller tilføj en lille lokal in-process cache foran Redis for de hotteste items.

## Interview-perspektiv

Intervieweren vil se dig tænke forbi "tilføj Redis". Godt: cache-aside med TTL. Fremragende: du navngiver **stampede protection, invalideringsstrategi, hot-key-håndtering, og hvad der sker ved et cache-udfald**. Fælden er at antage, at cachen altid er oppe — hvis Redis dør og hver miss falder igennem til DB'en, får du en **cache-avalanche**, der tager DB'en ned med.

## Trade-offs & fejlmåder

- **Forældelse vs belastning:** kort TTL = frisk men flere misses; lang TTL = færre misses men mere forældet. Indstil pr. data.
- **Cache avalanche:** mange nøgler der udløber sammen (samme TTL) forårsager en belastningsspike — **jitter** TTL'erne.
- **Konsistens:** cache og DB kan divergere; for penge-kritiske reads, læs DB'en eller brug write-through.
- **Memory eviction:** under pres evicter Redis efter policy (LRU/LFU); en forkert policy dropper lydløst dit hot set.

Cache-aside vs read-through

TTL + invalidering

Stampede protection & hot keys

Interview-perspektiv

Trade-offs & fejlmåder

Relaterede spørgsmål