Cum faci caching pentru a reduce încărcarea DB-ului la milioane de req/min?

Question

IT Interview Practice · Accepted Answer

Pune un strat **cache-aside** (Redis/Memcached) în fața DB-ului, astfel încât citirile să lovească memoria, dă intrărilor un **TTL** și **invalidează la scriere**, adaugă **protecție împotriva stampede**, astfel încât o cheie rece să nu poată dezlănțui un thundering herd pe DB, și distribuie **cheile fierbinți** pe replici, astfel încât o cheie populară să nu topească un singur 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

În **cache-aside** aplicația verifică cache-ul; la un miss citește DB-ul și populează cache-ul ea însăși. În **read-through** biblioteca de cache face asta pentru tine. Oricum, scopul este același: transformă o interogare DB de 5ms într-un lookup de memorie de 0,2ms, astfel încât un cache cu rată de hit de 95% taie traficul de citire al DB-ului de **20×**. La milioane de req/min DB-ul pur și simplu nu poate servi fiecare citire — cache-ul este ceea ce face cifrele să funcționeze.

## TTL + invalidare

Două moduri de a menține cache-ul proaspăt, și de obicei ai nevoie de amândouă. **TTL** delimitează învechirea — o intrare expiră după N secunde, deci datele greșite se auto-vindecă. **Invalidarea explicită** șterge/actualizează cheia la scriere pentru corectitudine care nu poate aștepta TTL-ul. Bug-ul clasic este caching fără invalidare și servirea datelor învechite minute întregi; cel mai subtil este invalidarea *și* setarea în aceeași scriere, ceea ce face race.

## Protecție împotriva stampede și chei fierbinți

- **Stampede (thundering herd):** când o cheie fierbinte expiră, mii de miss-uri concurente lovesc DB-ul deodată și îl pot doborî. Repară cu un **lock per cheie/single-flight** (doar un request recalculează, ceilalți așteaptă) sau **refresh timpuriu/probabilistic** înainte de expirare.
- **Chei fierbinți:** o cheie (profilul unei celebrități) poate satura CPU-ul/rețeaua unui singur nod Redis. Distribuie-o — replică cheia pe noduri, sau adaugă un mic cache local in-process în fața Redis pentru cele mai fierbinți elemente.

## Perspectiva de interviu

Intervievatorul vrea să te vadă gândind dincolo de "adaugă Redis". Bine: cache-aside cu TTL. Excelent: numești **protecția împotriva stampede, strategia de invalidare, gestionarea cheilor fierbinți și ce se întâmplă la o cădere de cache**. Capcana este să presupui că cache-ul este mereu activ — dacă Redis moare și fiecare miss cade prin la DB, obții un **cache-avalanche** care doboară și DB-ul.

## Compromisuri și moduri de eșec

- **Învechire vs încărcare:** TTL scurt = proaspăt, dar mai multe miss-uri; TTL lung = mai puține miss-uri, dar mai învechit. Reglează per date.
- **Cache avalanche:** multe chei expirând împreună (același TTL) cauzează un vârf de încărcare — adaugă **jitter** la TTL-uri.
- **Consistență:** cache-ul și DB-ul pot diverge; pentru citiri critice cu bani, citește DB-ul sau folosește write-through.
- **Eviction de memorie:** sub presiune, Redis face eviction după politică (LRU/LFU); o politică greșită elimină silențios setul tău fierbinte.

Cache-aside vs read-through

TTL + invalidare

Protecție împotriva stampede și chei fierbinți

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe