Hur cachar du för att minska DB-last vid miljontals req/min?

Question

IT Interview Practice · Accepted Answer

Sätt ett **cache-aside**-lager (Redis/Memcached) framför DB:n så att läsningar träffar minne, ge poster en **TTL** och **invalidera vid skrivning**, lägg till **stampede-skydd** så att en kall nyckel inte kan släppa loss en thundering herd mot DB:n, och sprid **heta nycklar** över replicas så att en populär nyckel inte smälter en enda nod.

```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** kontrollerar appen cachen; vid en miss läser den DB:n och populerar cachen själv. I **read-through** gör cache-biblioteket det åt dig. Hur som helst är målet detsamma: förvandla en 5ms DB-fråga till en 0,2ms minnesuppslagning, så att en cache med 95% hit rate minskar DB-lästrafik **20×**. Vid miljontals req/min kan DB:n helt enkelt inte betjäna varje läsning — cachen är det som får siffrorna att gå ihop.

## TTL + invalidering

Två sätt att hålla cachen färsk, och du behöver oftast båda. **TTL** begränsar inaktualitet — en post expirerar efter N sekunder så att felaktig data självläker. **Explicit invalidering** raderar/uppdaterar nyckeln vid skrivning för korrekthet som inte kan vänta på TTL. Den klassiska buggen är att cacha utan invalidering och servera inaktuell data i minuter; den subtilare är att invalidera *och* sätta i samma skrivning, vilket racear.

## Stampede-skydd & heta nycklar

- **Stampede (thundering herd):** när en het nyckel expirerar träffar tusentals samtidiga missar DB:n på en gång och kan välta den. Fixa med ett **per-nyckel-lås/single-flight** (bara en request räknar om, andra väntar) eller **tidig/probabilistisk refresh** före utgång.
- **Heta nycklar:** en nyckel (en kändis profil) kan mätta en enda Redis-nods CPU/nätverk. Sprid den — replikera nyckeln över noder, eller lägg till en liten lokal in-process-cache framför Redis för de hetaste objekten.

## Intervjuperspektiv

Intervjuaren vill se dig tänka bortom "lägg till Redis". Bra: cache-aside med TTL. Utmärkt: du namnger **stampede-skydd, invalideringsstrategi, hantering av heta nycklar, och vad som händer vid ett cache-avbrott**. Fällan är att anta att cachen alltid är uppe — om Redis dör och varje miss faller igenom till DB:n får du en **cache-avalanche** som tar ner DB:n också.

## Avvägningar & felmoder

- **Inaktualitet vs last:** kort TTL = färskt men fler missar; lång TTL = färre missar men mer inaktuellt. Justera per data.
- **Cache-avalanche:** många nycklar som expirerar tillsammans (samma TTL) orsakar en lasttopp — **jittra** TTL:erna.
- **Konsistens:** cache och DB kan divergera; för pengakritiska läsningar, läs DB:n eller använd write-through.
- **Minnes-eviction:** under press evictar Redis efter policy (LRU/LFU); en felaktig policy släpper tyst din heta mängd.

Cache-aside vs read-through

TTL + invalidering

Stampede-skydd & heta nycklar

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor