Hoe schaal je MySQL wanneer het verkeer 100x groeit?

Question

IT Interview Practice · Accepted Answer

Schaal in fases: **read replica's + caching voor reads eerst, daarna sharding (Vitess) voor writes** — en voeg connection pooling toe vóór al het andere, want dat is de goedkoopste 10x. Reads en writes schalen anders, dus grijp niet op dag één naar sharding.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ geef terug
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replicatie)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## Stap 0: connection pooling

Elke MySQL-connectie kost geheugen en een thread. Bij 100x verkeer put je `max_connections` uit lang voor de CPU. Een pooler als **ProxySQL** of **PgBouncer** multiplext duizenden app-connecties op een paar honderd DB-connecties. Het is een config-wijziging, geen herarchitectuur — doe het eerst.

## Stap 1: cache de reads

De meeste workloads zijn read-heavy (vaak 90%+). Zet **Redis** ervoor voor hot rows — gebruikersprofielen, productpagina's. Een cache hit raakt MySQL nooit. Gebruik cache-aside: lees cache → miss → lees DB → vul cache. Dit alleen al kan de meerderheid van de 100x absorberen.

## Stap 2: read replica's

Voeg **async read replica's** toe en route SELECTs erheen, writes naar de primary. Dit schaalt reads horizontaal: N replica's ≈ N× read-capaciteit. De addertje is **replicatie-lag** — een replica kan milliseconden tot seconden achterlopen, dus read-your-own-writes vraagt zorg (route de reads van die gebruiker naar de primary, of lees uit cache).

## Stap 3: shard de writes

Replica's helpen writes niet — elke write raakt nog steeds de enkele primary. Wanneer write-throughput één machine verzadigt, **shard**. **Vitess** (gebouwd bij YouTube) zit vóór MySQL en doet sharding, query-routing en online resharding zonder de app te herschrijven. Shard op `user_id` zodat de meeste queries single-shard blijven.

## Interviewperspectief

Interviewers letten op **volgorde**: kandidaten die meteen sharden verraden dat ze niet weten dat replica's/caching read-schaling veel goedkoper oplossen. Goed: "voeg replica's en een cache toe." Uitstekend: je scheidt het read-pad van het write-pad, benoemt replicatie-lag als de prijs van replica's, en introduceert sharding pas wanneer *writes* — niet reads — de bottleneck zijn.

**Veelvoorkomende valkuil:** "gewoon read replica's toevoegen" terwijl de echte bottleneck write-throughput is. Replica's maken dat *erger* (meer replicatiebelasting op de primary).

## Afwegingen & faalmodi

- **Replicatie-lag:** stale reads; pin kritieke reads aan de primary of gebruik semi-sync replicatie.
- **Cache stampede:** veel misses raken de DB tegelijk bij expiratie — gebruik locks of gespreide TTLs.
- **Sharding-complexiteit:** verliest cross-shard joins en transacties; betaal dit pas wanneer writes het afdwingen.
- **Failover:** de dood van de primary vereist geautomatiseerde promotie (Orchestrator); een stale gepromoveerde replica kan recente writes verliezen.

Stap 0: connection pooling

Stap 1: cache de reads

Stap 2: read replica's

Stap 3: shard de writes

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen