Jak cachovat pro snížení zátěže DB při milionech req/min?

Question

IT Interview Practice · Accepted Answer

Postavte před DB **cache-aside** vrstvu (Redis/Memcached), aby čtení zasáhla paměť, dejte záznamům **TTL** a **invalidujte při zápisu**, přidejte **ochranu proti stampede**, aby studený klíč nemohl spustit thundering herd na DB, a rozprostřete **hot keys** napříč replikami, aby jeden populární klíč neroztavil jeden 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

U **cache-aside** aplikace kontroluje cache; při missu přečte DB a naplní cache sama. U **read-through** to za vás dělá cache knihovna. V obou případech je cíl stejný: proměnit 5ms DB dotaz na 0,2ms lookup v paměti, takže cache s 95% hit rate sníží DB read provoz **20×**. Při milionech req/min DB prostě nemůže obsloužit každé čtení — cache je to, co umožňuje, aby čísla vycházela.

## TTL + invalidace

Dva způsoby, jak udržet cache čerstvou, a obvykle potřebujete oba. **TTL** ohraničuje zastaralost — záznam vyprší po N sekundách, takže špatná data se samy zahojí. **Explicitní invalidace** smaže/aktualizuje klíč při zápisu kvůli správnosti, která nemůže čekat na TTL. Klasický bug je cachovat bez invalidace a servírovat zastaralá data minuty; jemnější je invalidovat *a* nastavit ve stejném zápisu, což soupeří.

## Ochrana proti stampede & hot keys

- **Stampede (thundering herd):** když hot klíč vyprší, tisíce souběžných missů zasáhnou DB naráz a mohou ji shodit. Opravte **zámkem na klíč / single-flight** (jen jeden požadavek přepočítá, ostatní čekají) nebo **early/probabilistickým refreshem** před expirací.
- **Hot keys:** jeden klíč (profil celebrity) může nasytit CPU/síť jednoho Redis nodu. Rozprostřete jej — replikujte klíč napříč nodes, nebo přidejte malou lokální in-process cache před Redis pro nejhorčejší položky.

## Pohled z pohovoru

Tazatel chce vidět, že přemýšlíte za hranicí „přidej Redis“. Dobré: cache-aside s TTL. Skvělé: pojmenujete **ochranu proti stampede, strategii invalidace, práci s hot key a co se stane při výpadku cache**. Pastí je předpokládat, že cache je vždy nahoře — pokud Redis padne a každý miss propadne na DB, dostanete **cache-avalanche**, která shodí i DB.

## Kompromisy a selhání

- **Zastaralost vs zátěž:** krátký TTL = čerstvé, ale víc missů; dlouhý TTL = méně missů, ale zastaralejší. Laďte podle dat.
- **Cache avalanche:** mnoho klíčů vyprší současně (stejný TTL) způsobí špičku zátěže — **jitterujte** TTL.
- **Konzistence:** cache a DB se mohou rozejít; pro peněžně kritická čtení čtěte DB nebo použijte write-through.
- **Eviction paměti:** pod tlakem Redis evictuje podle politiky (LRU/LFU); špatná politika tiše zahodí váš hot set.

Cache-aside vs read-through

TTL + invalidace

Ochrana proti stampede & hot keys

Pohled z pohovoru

Kompromisy a selhání

Související otázky