Wie skalierst du MySQL, wenn der Traffic um das 100-fache wächst?

Question

IT Interview Practice · Accepted Answer

Skaliere in Stufen: **Read Replicas + Caching für Reads zuerst, dann Sharding (Vitess) für Writes** - und ergänze Connection Pooling vor allem anderen, denn es ist die günstigste 10x. Reads und Writes skalieren unterschiedlich, also greife nicht am ersten Tag zu Sharding.

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

## Schritt 0: Connection Pooling

Jede MySQL-Connection kostet Speicher und einen Thread. Bei 100x Traffic erschöpfst du `max_connections` lange vor der CPU. Ein Pooler wie **ProxySQL** oder **PgBouncer** multiplext Tausende App-Connections auf wenige Hundert DB-Connections. Es ist eine Config-Änderung, keine Neuarchitektur - tu es zuerst.

## Schritt 1: die Reads cachen

Die meisten Workloads sind read-heavy (oft 90%+). Setze **Redis** davor für heiße Rows - Nutzerprofile, Produktseiten. Ein Cache Hit berührt MySQL nie. Nutze Cache-aside: Cache lesen → Miss → DB lesen → Cache füllen. Allein das kann den Großteil der 100x absorbieren.

## Schritt 2: Read Replicas

Ergänze **async Read Replicas** und route SELECTs zu ihnen, Writes zum Primary. Das skaliert Reads horizontal: N Replicas ≈ N× Read-Kapazität. Der Haken ist der **Replication Lag** - eine Replica kann Millisekunden bis Sekunden hinterher sein, sodass Read-your-own-Writes Sorgfalt braucht (route die Reads dieses Nutzers zum Primary oder lies aus dem Cache).

## Schritt 3: die Writes sharden

Replicas helfen Writes nicht - jeder Write trifft weiterhin den einzelnen Primary. Wenn der Write-Throughput eine Box sättigt, **sharde**. **Vitess** (bei YouTube gebaut) sitzt vor MySQL und macht Sharding, Query-Routing und Online-Resharding, ohne die App neu zu schreiben. Sharde nach `user_id`, damit die meisten Queries Single-Shard bleiben.

## Interview-Perspektive

Interviewer achten auf die **Reihenfolge**: Kandidaten, die sofort sharden, verraten, dass sie nicht wissen, dass Replicas/Caching Read-Scaling weit günstiger lösen. Gut: "Replicas und einen Cache hinzufügen." Hervorragend: Du trennst den Read-Pfad vom Write-Pfad, benennst Replication Lag als Kosten der Replicas und führst Sharding erst ein, wenn *Writes* - nicht Reads - der Engpass sind.

**Häufige Falle:** "einfach Read Replicas hinzufügen", wenn der tatsächliche Engpass der Write-Throughput ist. Replicas machen das *schlimmer* (mehr Replikationslast auf dem Primary).

## Trade-offs & Fehlermodi

- **Replication Lag:** veraltete Reads; pinne kritische Reads auf den Primary oder nutze Semi-sync-Replikation.
- **Cache Stampede:** viele Misses treffen bei Ablauf gleichzeitig die DB - nutze Locks oder gestaffelte TTLs.
- **Sharding-Komplexität:** verliert Cross-Shard-Joins und -Transaktionen; zahle das erst, wenn Writes es erzwingen.
- **Failover:** Der Tod des Primary braucht automatisierte Promotion (Orchestrator); eine veraltete beförderte Replica kann jüngste Writes verlieren.

Schritt 0: Connection Pooling

Schritt 1: die Reads cachen

Schritt 2: Read Replicas

Schritt 3: die Writes sharden

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen