Si e shkallëzoni MySQL kur trafiku rritet 100x?

Question

IT Interview Practice · Accepted Answer

Shkallëzoni në faza: **read replicas + caching për leximet së pari, pastaj sharding (Vitess) për shkrimet** — dhe shtoni connection pooling para gjithçkaje, sepse është 10x-i më i lirë. Leximet dhe shkrimet shkallëzohen ndryshe, kështu që mos u kapni pas sharding-ut ditën e parë.

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

## Hapi 0: connection pooling

Çdo lidhje MySQL kushton memorie dhe një thread. Në trafik 100x do të shterni `max_connections` shumë para CPU-së. Një pooler si **ProxySQL** ose **PgBouncer** multiplekson mijëra lidhje aplikacioni në disa qindra lidhje DB. Është një ndryshim konfigurimi, jo një riarkitekturë — bëjeni së pari.

## Hapi 1: cache leximet

Shumica e workload-eve janë read-heavy (shpesh 90%+). Vendosni **Redis** përpara për rreshtat e nxehtë — profile përdoruesish, faqe produktesh. Një cache hit kurrë nuk prek MySQL. Përdorni cache-aside: lexo cache → miss → lexo DB → popullo cache. Kjo e vetme mund të thithë shumicën e 100x-it.

## Hapi 2: read replicas

Shtoni **async read replicas** dhe drejtoni SELECT-et te ato, shkrimet te primary. Kjo shkallëzon leximet horizontalisht: N replicas ≈ N× kapacitet leximi. Kapja është **replication lag** — një replica mund të jetë milisekonda-deri-sekonda prapa, kështu që read-your-own-writes kërkon kujdes (drejtoni leximet e atij përdoruesi te primary, ose lexoni nga cache).

## Hapi 3: shard shkrimet

Replica-t nuk ndihmojnë shkrimet — çdo shkrim ende godet primary-n e vetëm. Kur write throughput ngop një kuti, **shard**. **Vitess** (i ndërtuar në YouTube) rri përpara MySQL dhe bën sharding, query routing, dhe resharding online pa rishkruar aplikacionin. Shard sipas `user_id` që shumica e query-ve të mbeten single-shard.

## Këndvështrimi i intervistës

Intervistuesit shohin për **renditjen**: kandidatët që menjëherë bëjnë sharding zbulojnë se nuk dinë që replicas/caching e zgjidhin read scaling shumë më lirë. Mirë: "shto replicas dhe një cache." E shkëlqyer: ndani read path nga write path, emërtoni replication lag si koston e replica-ve, dhe futni sharding vetëm kur *shkrimet* — jo leximet — janë bottleneck.

**Kurthi i zakonshëm:** "thjesht shto read replicas" kur bottleneck-u i vërtetë është write throughput. Replica-t e bëjnë atë *më keq* (më shumë ngarkesë replikimi në primary).

## Kompromiset & mënyrat e dështimit

- **Replication lag:** lexime të vjetruara; pin-oni leximet kritike te primary ose përdorni semi-sync replication.
- **Cache stampede:** shumë miss godasin DB-në njëkohësisht në skadim — përdorni locks ose TTL të shpërndara.
- **Kompleksiteti i sharding:** humbet cross-shard joins dhe transactions; paguajeni këtë vetëm kur shkrimet e detyrojnë.
- **Failover:** vdekja e primary kërkon promovim të automatizuar (Orchestrator); një replica e vjetruar e promovuar mund të humbë shkrime të fundit.

Hapi 0: connection pooling

Hapi 1: cache leximet

Hapi 2: read replicas

Hapi 3: shard shkrimet

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme