Kif tiskala MySQL meta t-traffiku jikber 100x?

Question

IT Interview Practice · Accepted Answer

Skala fi stadji: **read replicas + caching għall-reads l-ewwel, imbagħad sharding (Vitess) għall-writes** — u żid connection pooling qabel kollox, għax huwa l-irħas 10x. Ir-reads u l-writes jiskalaw b'mod differenti, allura tmurx għal sharding fl-ewwel ġurnata.

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

## Pass 0: connection pooling

Kull connection ta' MySQL tiswa memorja u thread. B'100x traffiku tispiċċa l-`max_connections` ħafna qabel is-CPU. Pooler bħal **ProxySQL** jew **PgBouncer** jimmultiplexja eluf ta' connections tal-app fuq ftit mijiet ta' connections tad-DB. Huwa bidla fil-config, mhux ri-arkitettura — agħmlu l-ewwel.

## Pass 1: ikkaċċja r-reads

Ħafna workloads huma read-heavy (spiss 90%+). Poġġi **Redis** quddiem għal rows jaħarqu — profili tal-utent, paġni tal-prodotti. Cache hit qatt ma jmiss MySQL. Uża cache-aside: aqra cache → miss → aqra DB → imla cache. Dan waħdu jista' jassorbi l-maġġoranza tal-100x.

## Pass 2: read replicas

Żid **async read replicas** u idderieġi s-SELECTs lejhom, il-writes lejn il-primary. Dan jiskala r-reads orizzontalment: N replicas ≈ N× kapaċità ta' read. Il-qabda hija r-**replication lag** — replica jista' jkun millisekondi-sa-sekondi lura, allura read-your-own-writes jeħtieġ attenzjoni (idderieġi r-reads ta' dak l-utent lejn il-primary, jew aqra mill-cache).

## Pass 3: shard il-writes

Ir-replicas ma jgħinux il-writes — kull write għadu jolqot il-primary wieħed. Meta t-throughput tal-writes jissatura box wieħed, **agħmel shard**. **Vitess** (mibnija f'YouTube) toqgħod quddiem MySQL u tagħmel sharding, query routing, u online resharding mingħajr ma terġa' tikteb l-app. Shard skont `user_id` biex ħafna queries jibqgħu single-shard.

## Perspettiva tal-intervista

L-intervistaturi jaraw għall-**ordni**: kandidati li jagħmlu shard mill-ewwel jiżvelaw li ma jafux li r-replicas/caching isolvu read scaling ħafna irħas. Tajjeb: "żid replicas u cache." Eċċellenti: tissepara l-read path mill-write path, issemmi replication lag bħala l-kost tar-replicas, u ddaħħal sharding biss meta l-*writes* — mhux ir-reads — huma l-bottleneck.

**Nassa komuni:** "sempliċiment żid read replicas" meta l-bottleneck attwali huwa write throughput. Ir-replicas jagħmluh *agħar* (aktar replication load fuq il-primary).

## Trade-offs u modi ta' fallimenti

- **Replication lag:** reads staljati; ipponta r-reads kritiċi lejn il-primary jew uża semi-sync replication.
- **Cache stampede:** ħafna misses jolqtu d-DB f'daqqa mal-iskadenza — uża locks jew staggered TTLs.
- **Kumplessità tas-sharding:** titlef cross-shard joins u transactions; ħallas dan biss ladarba l-writes jġiegħlek.
- **Failover:** mewt tal-primary teħtieġ promozzjoni awtomatizzata (Orchestrator); replica promoss staljat jista' jitlef writes reċenti.

Pass 0: connection pooling

Pass 1: ikkaċċja r-reads

Pass 2: read replicas

Pass 3: shard il-writes

Perspettiva tal-intervista

Trade-offs u modi ta' fallimenti

Mistoqsijiet relatati