Comment scalez-vous MySQL quand le trafic croît de 100x ?

Question

IT Interview Practice · Accepted Answer

Scalez par étapes : **read replicas + caching pour les lectures d'abord, puis sharding (Vitess) pour les écritures** — et ajoutez du connection pooling avant tout, car c'est le 10x le moins cher. Les lectures et les écritures scalent différemment, donc ne recourez pas au sharding dès le premier jour.

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

## Étape 0 : connection pooling

Chaque connexion MySQL coûte de la mémoire et un thread. À 100x le trafic vous épuiserez `max_connections` bien avant le CPU. Un pooler comme **ProxySQL** ou **PgBouncer** multiplexe des milliers de connexions applicatives sur quelques centaines de connexions DB. C'est un changement de config, pas une ré-architecture — faites-le en premier.

## Étape 1 : cacher les lectures

La plupart des charges sont read-heavy (souvent 90%+). Placez **Redis** en front pour les lignes chaudes — profils utilisateur, pages produit. Un cache hit ne touche jamais MySQL. Utilisez le cache-aside : lire le cache → miss → lire la DB → peupler le cache. Cela seul peut absorber la majorité du 100x.

## Étape 2 : read replicas

Ajoutez des **read replicas asynchrones** et routez les SELECT vers eux, les écritures vers le primary. Cela scale les lectures horizontalement : N réplicas ≈ N× la capacité de lecture. Le hic est le **replication lag** — un réplica peut avoir des millisecondes à des secondes de retard, donc le read-your-own-writes demande de l'attention (routez les lectures de cet utilisateur vers le primary, ou lisez depuis le cache).

## Étape 3 : sharder les écritures

Les réplicas n'aident pas les écritures — chaque écriture frappe toujours l'unique primary. Quand le throughput d'écriture sature une machine, **shardez**. **Vitess** (construit chez YouTube) se place devant MySQL et fait le sharding, le routage de requêtes et le resharding en ligne sans réécrire l'application. Shardez par `user_id` pour que la plupart des requêtes restent single-shard.

## Perspective d'entretien

Les examinateurs guettent l'**ordre** : les candidats qui shardent immédiatement révèlent qu'ils ignorent que réplicas/caching résolvent le scaling des lectures bien plus à moindre coût. Bien : « ajouter des réplicas et un cache ». Excellent : vous séparez le chemin de lecture du chemin d'écriture, nommez le replication lag comme le coût des réplicas, et n'introduisez le sharding que lorsque les *écritures* — non les lectures — sont le goulot.

**Piège courant :** « juste ajouter des read replicas » quand le vrai goulot est le throughput d'écriture. Les réplicas aggravent cela (plus de charge de réplication sur le primary).

## Compromis et pannes

- **Replication lag :** lectures périmées ; épinglez les lectures critiques au primary ou utilisez la réplication semi-synchrone.
- **Cache stampede :** de nombreux misses frappent la DB en même temps à l'expiration — utilisez des verrous ou des TTL échelonnés.
- **Complexité du sharding :** perd les jointures et transactions cross-shard ; ne payez cela qu'une fois que les écritures l'imposent.
- **Failover :** la mort du primary nécessite une promotion automatisée (Orchestrator) ; un réplica promu périmé peut perdre des écritures récentes.

Étape 0 : connection pooling

Étape 1 : cacher les lectures

Étape 2 : read replicas

Étape 3 : sharder les écritures

Perspective d'entretien

Compromis et pannes

Questions connexes