Como você escala o MySQL quando o tráfego cresce 100x?

Question

IT Interview Practice · Accepted Answer

Escale em estágios: **read replicas + caching para leituras primeiro, depois sharding (Vitess) para escritas** — e adicione connection pooling antes de tudo, porque é o 10x mais barato. Leituras e escritas escalam de forma diferente, então não recorra a sharding no primeiro dia.

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

## Passo 0: connection pooling

Cada conexão MySQL custa memória e uma thread. Com 100x de tráfego você esgotará `max_connections` muito antes da CPU. Um pooler como **ProxySQL** ou **PgBouncer** multiplexa milhares de conexões de app em algumas centenas de conexões de DB. É uma mudança de config, não uma rearquitetura — faça primeiro.

## Passo 1: cachear as leituras

A maioria das cargas é read-heavy (frequentemente 90%+). Coloque o **Redis** na frente para linhas quentes — perfis de usuário, páginas de produto. Um cache hit nunca toca o MySQL. Use cache-aside: ler cache → miss → ler DB → popular cache. Só isso já pode absorver a maior parte do 100x.

## Passo 2: read replicas

Adicione **read replicas assíncronas** e roteie SELECTs para elas, escritas para o primário. Isso escala leituras horizontalmente: N réplicas ≈ N× capacidade de leitura. O problema é o **replication lag** — uma réplica pode estar de milissegundos a segundos atrás, então read-your-own-writes precisa de cuidado (roteie as leituras daquele usuário para o primário, ou leia do cache).

## Passo 3: fazer sharding das escritas

Réplicas não ajudam nas escritas — toda escrita ainda bate no único primário. Quando o throughput de escrita satura uma máquina, **faça sharding**. O **Vitess** (construído no YouTube) fica na frente do MySQL e faz sharding, roteamento de consultas e resharding online sem reescrever o app. Faça sharding por `user_id` para que a maioria das consultas fique em um único shard.

## Perspectiva de entrevista

Entrevistadores observam a **ordem**: candidatos que imediatamente fazem sharding revelam que não sabem que réplicas/caching resolvem o scaling de leitura de forma muito mais barata. Bom: "adicionar réplicas e um cache." Excelente: você separa o caminho de leitura do caminho de escrita, nomeia replication lag como o custo das réplicas e só introduz sharding quando as *escritas* — não as leituras — são o gargalo.

**Armadilha comum:** "só adicione read replicas" quando o gargalo real é o throughput de escrita. Réplicas pioram isso (mais carga de replicação no primário).

## Trade-offs e modos de falha

- **Replication lag:** leituras stale; fixe leituras críticas no primário ou use replicação semi-sync.
- **Cache stampede:** muitos misses batem no DB de uma vez na expiração — use locks ou TTLs escalonados.
- **Complexidade de sharding:** perde joins e transações cross-shard; só pague isso quando as escritas forçarem.
- **Failover:** a morte do primário precisa de promoção automatizada (Orchestrator); uma réplica promovida stale pode perder escritas recentes.

Passo 0: connection pooling

Passo 1: cachear as leituras

Passo 2: read replicas

Passo 3: fazer sharding das escritas

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas