Cum scalezi MySQL când traficul crește de 100x?

Question

IT Interview Practice · Accepted Answer

Scalează în etape: **read replicas + caching pentru citiri mai întâi, apoi sharding (Vitess) pentru scrieri** — și adaugă connection pooling înainte de orice altceva, pentru că este cel mai ieftin 10x. Citirile și scrierile scalează diferit, deci nu apela la sharding din prima zi.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ return
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replication)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## Pasul 0: connection pooling

Fiecare conexiune MySQL costă memorie și un thread. La trafic 100x vei epuiza `max_connections` cu mult înainte de CPU. Un pooler precum **ProxySQL** sau **PgBouncer** multiplexează mii de conexiuni de aplicație pe câteva sute de conexiuni de DB. Este o schimbare de config, nu o re-arhitecturare — fă-o prima.

## Pasul 1: pune citirile în cache

Majoritatea workload-urilor sunt read-heavy (adesea 90%+). Pune **Redis** în față pentru rândurile fierbinți — profiluri de utilizator, pagini de produs. Un cache hit nu atinge niciodată MySQL. Folosește cache-aside: citește cache → miss → citește DB → populează cache. Doar asta poate absorbi majoritatea celor 100x.

## Pasul 2: read replicas

Adaugă **read replicas async** și rutează SELECT-urile către ele, scrierile către primary. Asta scalează citirile orizontal: N replici ≈ N× capacitate de citire. Problema este **replication lag** — o replică poate fi în urmă cu milisecunde-până-la-secunde, deci read-your-own-writes necesită grijă (rutează citirile acelui utilizator către primary, sau citește din cache).

## Pasul 3: fă sharding pe scrieri

Replicile nu ajută scrierile — fiecare scriere tot lovește singurul primary. Când throughput-ul de scriere saturează o singură mașină, **fă sharding**. **Vitess** (construit la YouTube) stă în fața MySQL și face sharding, rutare de interogări și resharding online fără a rescrie aplicația. Fă sharding după `user_id`, astfel încât majoritatea interogărilor să rămână single-shard.

## Perspectiva de interviu

Intervievatorii urmăresc **ordinea**: candidații care fac sharding imediat dezvăluie că nu știu că replicile/caching-ul rezolvă scalarea citirilor mult mai ieftin. Bine: "adaugă replici și un cache." Excelent: separi calea de citire de calea de scriere, numești replication lag ca fiind costul replicilor și introduci sharding-ul doar când *scrierile* — nu citirile — sunt blocajul.

**Capcană obișnuită:** "pur și simplu adaugă read replicas" când blocajul real este throughput-ul de scriere. Replicile fac asta *mai rău* (mai multă încărcare de replicare pe primary).

## Compromisuri și moduri de eșec

- **Replication lag:** citiri învechite; fixează citirile critice pe primary sau folosește replicare semi-sync.
- **Cache stampede:** multe miss-uri lovesc DB-ul deodată la expirare — folosește lock-uri sau TTL-uri eșalonate.
- **Complexitatea sharding-ului:** pierde join-urile și tranzacțiile cross-shard; plătește asta doar când scrierile te forțează.
- **Failover:** moartea primary-ului necesită promovare automată (Orchestrator); o replică promovată învechită poate pierde scrieri recente.

Pasul 0: connection pooling

Pasul 1: pune citirile în cache

Pasul 2: read replicas

Pasul 3: fă sharding pe scrieri

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe