Come scali MySQL quando il traffico cresce di 100x?

Question

IT Interview Practice · Accepted Answer

Scala per fasi: **prima read replica + caching per le letture, poi sharding (Vitess) per le scritture** — e aggiungi il connection pooling prima di ogni altra cosa, perché è il 10x più economico. Letture e scritture scalano in modo diverso, quindi non ricorrere allo sharding il primo giorno.

```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
```

## Fase 0: connection pooling

Ogni connessione MySQL costa memoria e un thread. A 100x di traffico esaurirai `max_connections` molto prima della CPU. Un pooler come **ProxySQL** o **PgBouncer** multiplexa migliaia di connessioni applicative su poche centinaia di connessioni DB. È un cambio di configurazione, non una riarchitettura — fallo per primo.

## Fase 1: metti in cache le letture

La maggior parte dei workload è read-heavy (spesso 90%+). Metti **Redis** davanti per le righe calde — profili utente, pagine prodotto. Un cache hit non tocca mai MySQL. Usa cache-aside: leggi cache → miss → leggi DB → popola cache. Questo da solo può assorbire la maggior parte del 100x.

## Fase 2: read replica

Aggiungi **read replica asincrone** e instrada le SELECT verso di esse, le scritture verso il primary. Questo scala le letture orizzontalmente: N replica ≈ N× capacità di lettura. Il rovescio è il **replication lag** — una replica può essere indietro di millisecondi-secondi, quindi leggere le proprie scritture richiede attenzione (instrada le letture di quell'utente verso il primary, o leggi dalla cache).

## Fase 3: sharding delle scritture

Le replica non aiutano le scritture — ogni scrittura colpisce comunque l'unico primary. Quando il throughput in scrittura satura una macchina, **fai sharding**. **Vitess** (costruito in YouTube) si mette davanti a MySQL e gestisce sharding, query routing e resharding online senza riscrivere l'app. Fai sharding per `user_id` così che la maggior parte delle query resti single-shard.

## Prospettiva del colloquio

Gli intervistatori osservano l'**ordinamento**: i candidati che fanno subito sharding rivelano di non sapere che replica/caching risolvono lo scaling delle letture in modo molto più economico. Buono: "aggiungi replica e una cache." Eccellente: separi il percorso di lettura da quello di scrittura, nomini il replication lag come costo delle replica, e introduci lo sharding solo quando il collo di bottiglia sono le *scritture*, non le letture.

**Trappola comune:** "basta aggiungere read replica" quando il vero collo di bottiglia è il throughput in scrittura. Le replica lo peggiorano (più carico di replica sul primary).

## Compromessi e modalità di guasto

- **Replication lag:** letture stale; ancora le letture critiche al primary o usa la replica semi-sync.
- **Cache stampede:** molti miss colpiscono il DB insieme alla scadenza — usa lock o TTL scaglionati.
- **Complessità dello sharding:** perde join e transazioni cross-shard; paga questo prezzo solo quando le scritture lo impongono.
- **Failover:** la morte del primary richiede promozione automatica (Orchestrator); una replica promossa stale può perdere scritture recenti.

Fase 0: connection pooling

Fase 1: metti in cache le letture

Fase 2: read replica

Fase 3: sharding delle scritture

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate