Hoe cache je om DB-belasting te verlagen bij miljoenen req/min?

Question

IT Interview Practice · Accepted Answer

Zet een **cache-aside**-laag (Redis/Memcached) vóór de DB zodat reads het geheugen raken, geef entries een **TTL** en **invalideer bij write**, voeg **stampede-bescherming** toe zodat een koude key geen thundering herd op de DB kan loslaten, en spreid **hot keys** over replica's zodat één populaire key niet één node laat smelten.

```text
                 ┌── hit ──▶ geef waarde terug
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB-read ─▶ set(TTL) ─▶ geef terug
                              │
                    (alleen ÉÉN miss vult; anderen wachten)
DB-writes ──▶ invalideer/update key
```

## Cache-aside versus read-through

In **cache-aside** checkt de app de cache; bij een miss leest hij de DB en vult de cache zelf. In **read-through** doet de cache-library dat voor je. Hoe dan ook is het doel hetzelfde: een DB-query van 5ms omzetten in een geheugen-lookup van 0,2ms, zodat een cache met 95% hit rate het DB-read-verkeer **20×** verlaagt. Bij miljoenen req/min kan de DB simpelweg niet elke read bedienen — de cache is wat de cijfers laat kloppen.

## TTL + invalidatie

Twee manieren om de cache vers te houden, en je hebt meestal beide nodig. **TTL** begrenst staleness — een entry verloopt na N seconden zodat foute data zichzelf herstelt. **Expliciete invalidatie** verwijdert/update de key bij write voor correctheid die niet op TTL kan wachten. De klassieke bug is cachen zonder invalidatie en minutenlang stale data serveren; de subtielere is invalideren *en* setten in dezelfde write, wat racet.

## Stampede-bescherming & hot keys

- **Stampede (thundering herd):** wanneer een hot key verloopt, raken duizenden gelijktijdige misses de DB tegelijk en kunnen hem omgooien. Fix met een **per-key lock/single-flight** (slechts één request herberekent, anderen wachten) of **vroege/probabilistische refresh** vóór expiratie.
- **Hot keys:** één key (het profiel van een celebrity) kan de CPU/netwerk van één Redis-node verzadigen. Spreid het — repliceer de key over nodes, of voeg een kleine lokale in-process cache toe vóór Redis voor de heetste items.

## Interviewperspectief

De interviewer wil je verder zien denken dan "voeg Redis toe". Goed: cache-aside met TTL. Uitstekend: je benoemt **stampede-bescherming, invalidatiestrategie, hot-key-afhandeling, en wat er gebeurt bij een cache-storing**. De valkuil is aannemen dat de cache altijd up is — als Redis sterft en elke miss doorvalt naar de DB, krijg je een **cache-avalanche** die ook de DB neerhaalt.

## Afwegingen & faalmodi

- **Staleness versus belasting:** korte TTL = vers maar meer misses; lange TTL = minder misses maar staler. Tune per data.
- **Cache avalanche:** veel keys die samen verlopen (dezelfde TTL) veroorzaken een belastingspiek — **jitter** de TTLs.
- **Consistentie:** cache en DB kunnen divergeren; voor geld-kritieke reads, lees de DB of gebruik write-through.
- **Memory eviction:** onder druk evict Redis volgens beleid (LRU/LFU); een verkeerd beleid dropt stilletjes je hot set.

Cache-aside versus read-through

TTL + invalidatie

Stampede-bescherming & hot keys

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen