Hvordan skalerer du MySQL når trafikken vokser 100x?

Question

IT Interview Practice · Accepted Answer

Skaler i trinn: **read replicas + caching for lesninger først, deretter sharding (Vitess) for writes** — og legg til connection pooling før noe annet, fordi det er den billigste 10x-en. Lesninger og writes skalerer ulikt, så ikke grip til sharding på dag én.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ returner
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── lesninger ─────┼─▶ Read replica 2 ┼─ (async replikering)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (senere) Vitess shards ─▶ Primary A / Primary B
```

## Trinn 0: connection pooling

Hver MySQL-connection koster minne og en tråd. Ved 100x trafikk vil du uttømme `max_connections` lenge før CPU. En pooler som **ProxySQL** eller **PgBouncer** multiplexer tusenvis av app-connections på noen få hundre DB-connections. Det er en config-endring, ikke en rearkitektur — gjør det først.

## Trinn 1: cache lesningene

De fleste workloads er leselastige (ofte 90%+). Sett **Redis** foran for hot rows — brukerprofiler, produktsider. En cache hit treffer aldri MySQL. Bruk cache-aside: les cache → miss → les DB → populer cache. Dette alene kan absorbere størstedelen av 100x-en.

## Trinn 2: read replicas

Legg til **async read replicas** og rut SELECT-er til dem, writes til primary. Dette skalerer lesninger horisontalt: N replicas ≈ N× lesekapasitet. Haken er **replication lag** — en replica kan være millisekunder-til-sekunder bak, så read-your-own-writes trenger omtanke (rut den brukerens lesninger til primary, eller les fra cache).

## Trinn 3: shard writene

Replicas hjelper ikke writes — hver write treffer fortsatt den ene primaryen. Når write-throughput metter én boks, **shard**. **Vitess** (bygd hos YouTube) sitter foran MySQL og gjør sharding, query-routing og online resharding uten å skrive om appen. Shard på `user_id` slik at de fleste spørringer forblir single-shard.

## Intervjuperspektiv

Intervjuere ser etter **rekkefølge**: kandidater som umiddelbart sharder avslører at de ikke vet at replicas/caching løser lese-skalering langt billigere. Bra: "legg til replicas og en cache." Utmerket: du separerer lese-stien fra write-stien, navngir replication lag som kostnaden ved replicas, og innfører sharding kun når *writes* — ikke lesninger — er flaskehalsen.

**Vanlig felle:** "bare legg til read replicas" når den faktiske flaskehalsen er write-throughput. Replicas gjør det *verre* (mer replikeringsbelastning på primaryen).

## Avveininger og feilmoduser

- **Replication lag:** stale lesninger; pin kritiske lesninger til primary eller bruk semi-sync replikering.
- **Cache stampede:** mange misses treffer DB samtidig ved utløp — bruk locks eller forskjøvne TTL-er.
- **Sharding-kompleksitet:** mister cross-shard joins og transaksjoner; betal dette kun når writes tvinger det.
- **Failover:** primary-død trenger automatisert promotering (Orchestrator); en stale promotert replica kan miste nylige writes.

Trinn 0: connection pooling

Trinn 1: cache lesningene

Trinn 2: read replicas

Trinn 3: shard writene

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål