¿Cómo escalas MySQL cuando el tráfico crece 100x?

Question

IT Interview Practice · Accepted Answer

Escala por etapas: **read replicas + caching para las lecturas primero, luego sharding (Vitess) para las escrituras** — y añade connection pooling antes que nada, porque es el 10x más barato. Las lecturas y las escrituras escalan de forma distinta, así que no recurras al sharding el día uno.

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

## Paso 0: connection pooling

Cada conexión de MySQL cuesta memoria y un hilo. A 100x de tráfico agotarás `max_connections` mucho antes que la CPU. Un pooler como **ProxySQL** o **PgBouncer** multiplexa miles de conexiones de la app sobre unos pocos cientos de conexiones de DB. Es un cambio de config, no una rearquitectura — hazlo primero.

## Paso 1: cachea las lecturas

La mayoría de las cargas son read-heavy (a menudo 90%+). Pon **Redis** por delante para las filas calientes — perfiles de usuario, páginas de producto. Un cache hit nunca toca MySQL. Usa cache-aside: lee cache → miss → lee DB → puebla cache. Esto por sí solo puede absorber la mayor parte del 100x.

## Paso 2: read replicas

Añade **read replicas asíncronas** y enruta los SELECT hacia ellas, las escrituras al primary. Esto escala las lecturas horizontalmente: N réplicas ≈ N× de capacidad de lectura. La trampa es el **replication lag** — una réplica puede ir milisegundos-a-segundos por detrás, así que el read-your-own-writes requiere cuidado (enruta las lecturas de ese usuario al primary, o lee desde la cache).

## Paso 3: fragmenta las escrituras

Las réplicas no ayudan a las escrituras — cada escritura sigue golpeando el único primary. Cuando el throughput de escritura satura una máquina, **fragmenta**. **Vitess** (construido en YouTube) se sienta frente a MySQL y hace sharding, enrutamiento de queries y resharding online sin reescribir la app. Fragmenta por `user_id` para que la mayoría de las queries se queden single-shard.

## Perspectiva de la entrevista

Los entrevistadores vigilan el **orden**: los candidatos que fragmentan de inmediato revelan que no saben que las réplicas/caching resuelven el escalado de lecturas mucho más barato. Bueno: "añade réplicas y una cache." Excelente: separas la ruta de lectura de la de escritura, nombras el replication lag como el coste de las réplicas, y solo introduces sharding cuando las *escrituras* — no las lecturas — son el cuello de botella.

**Trampa común:** "solo añade read replicas" cuando el cuello de botella real es el throughput de escritura. Las réplicas lo empeoran (más carga de replicación en el primary).

## Compensaciones y modos de fallo

- **Replication lag:** lecturas obsoletas; fija las lecturas críticas al primary o usa replicación semi-síncrona.
- **Cache stampede:** muchos misses golpean la DB a la vez al expirar — usa locks o TTLs escalonados.
- **Complejidad del sharding:** pierde joins y transacciones cross-shard; solo paga esto una vez que las escrituras lo fuercen.
- **Failover:** la muerte del primary necesita promoción automatizada (Orchestrator); una réplica promovida obsoleta puede perder escrituras recientes.

Paso 0: connection pooling

Paso 1: cachea las lecturas

Paso 2: read replicas

Paso 3: fragmenta las escrituras

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas