Hur skalar du MySQL när trafiken växer 100x?

Question

IT Interview Practice · Accepted Answer

Skala i steg: **read replicas + caching för läsningar först, sedan sharding (Vitess) för skrivningar** — och lägg till connection pooling före allt annat, eftersom det är den billigaste 10x:en. Läsningar och skrivningar skalar olika, så grip inte efter sharding dag ett.

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

## Steg 0: connection pooling

Varje MySQL-anslutning kostar minne och en tråd. Vid 100x trafik kommer du att tömma `max_connections` långt före CPU. En pooler som **ProxySQL** eller **PgBouncer** multiplexar tusentals app-anslutningar på några hundra DB-anslutningar. Det är en konfigurationsändring, inte en omarkitektur — gör det först.

## Steg 1: cacha läsningarna

De flesta arbetslaster är lästunga (ofta 90%+). Sätt **Redis** framför för heta rader — användarprofiler, produktsidor. En cache hit rör aldrig MySQL. Använd cache-aside: läs cache → miss → läs DB → populera cache. Detta ensamt kan absorbera merparten av 100x:en.

## Steg 2: read replicas

Lägg till **asynkrona read replicas** och dirigera SELECTs till dem, skrivningar till primary. Detta skalar läsningar horisontellt: N replicas ≈ N× läskapacitet. Haken är **replication lag** — en replica kan ligga millisekunder-till-sekunder efter, så read-your-own-writes behöver omsorg (dirigera den användarens läsningar till primary, eller läs från cache).

## Steg 3: sharda skrivningarna

Replicas hjälper inte skrivningar — varje skrivning träffar fortfarande den enda primary:n. När skriv-throughput mättar en maskin, **sharda**. **Vitess** (byggt på YouTube) sitter framför MySQL och gör sharding, query routing och online-resharding utan att skriva om appen. Sharda på `user_id` så att de flesta frågor förblir single-shard.

## Intervjuperspektiv

Intervjuare bevakar **ordningen**: kandidater som omedelbart shardar avslöjar att de inte vet att replicas/caching löser läsningsskalning långt billigare. Bra: "lägg till replicas och en cache." Utmärkt: du separerar läsvägen från skrivvägen, namnger replication lag som replicas kostnad, och inför sharding bara när *skrivningar* — inte läsningar — är flaskhalsen.

**Vanlig fälla:** "bara lägg till read replicas" när den faktiska flaskhalsen är skriv-throughput. Replicas gör det *värre* (mer replikeringslast på primary).

## Avvägningar & felmoder

- **Replication lag:** inaktuella läsningar; pinna kritiska läsningar till primary eller använd semi-sync replication.
- **Cache stampede:** många missar träffar DB på en gång vid utgång — använd lås eller staggrade TTL:er.
- **Sharding-komplexitet:** förlorar cross-shard joins och transaktioner; betala detta bara när skrivningar tvingar fram det.
- **Failover:** primary-död behöver automatiserad promotion (Orchestrator); en inaktuell befordrad replica kan förlora nyliga skrivningar.

Steg 0: connection pooling

Steg 1: cacha läsningarna

Steg 2: read replicas

Steg 3: sharda skrivningarna

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor