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

Question

IT Interview Practice · Accepted Answer

Skalér i etaper: **read replicas + caching for reads først, derefter sharding (Vitess) for writes** — og tilføj connection pooling før noget andet, fordi det er den billigste 10x. Reads og writes skalerer forskelligt, så grib ikke efter sharding på dag ét.

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

## Trin 0: connection pooling

Hver MySQL-connection koster hukommelse og en thread. Ved 100x trafik udtømmer du `max_connections` længe før CPU. En pooler som **ProxySQL** eller **PgBouncer** multiplexer tusindvis af app-connections over på nogle få hundrede DB-connections. Det er en config-ændring, ikke en rearkitektur — gør det først.

## Trin 1: cache reads

De fleste workloads er read-tunge (ofte 90%+). Sæt **Redis** foran for hotte rows — brugerprofiler, produktsider. Et cache hit rører aldrig MySQL. Brug cache-aside: læs cache → miss → læs DB → populér cache. Dette alene kan absorbere hovedparten af de 100x.

## Trin 2: read replicas

Tilføj **async read replicas** og rout SELECTs til dem, writes til primary. Dette skalerer reads horisontalt: N replicas ≈ N× read-kapacitet. Haken er **replication lag** — en replica kan være millisekunder-til-sekunder bagud, så read-your-own-writes kræver omhu (rout den brugers reads til primary, eller læs fra cache).

## Trin 3: shard writes

Replicas hjælper ikke writes — hver write rammer stadig den ene primary. Når write-throughput mætter én maskine, **shard**. **Vitess** (bygget hos YouTube) sidder foran MySQL og udfører sharding, query routing og online resharding uden at omskrive appen. Shard efter `user_id`, så de fleste forespørgsler forbliver single-shard.

## Interview-perspektiv

Interviewere holder øje med **rækkefølgen**: kandidater der straks sharder, afslører, at de ikke ved, at replicas/caching løser read-skalering langt billigere. Godt: "tilføj replicas og en cache." Fremragende: du adskiller read-path fra write-path, navngiver replication lag som omkostningen ved replicas, og indfører kun sharding, når *writes* — ikke reads — er flaskehalsen.

**Almindelig fælde:** "bare tilføj read replicas", når den faktiske flaskehals er write-throughput. Replicas gør det *værre* (mere replication-belastning på primary).

## Trade-offs & fejlmåder

- **Replication lag:** forældede reads; pin kritiske reads til primary eller brug semi-sync replication.
- **Cache stampede:** mange misses rammer DB på én gang ved udløb — brug locks eller forskudte TTL'er.
- **Sharding-kompleksitet:** mister cross-shard joins og transactions; betal kun dette, når writes tvinger det.
- **Failover:** primary-død kræver automatiseret promotion (Orchestrator); en forældet promoveret replica kan miste nylige writes.

Trin 0: connection pooling

Trin 1: cache reads

Trin 2: read replicas

Trin 3: shard writes

Interview-perspektiv

Trade-offs & fejlmåder

Relaterede spørgsmål