Bagaimana Anda menskalakan MySQL saat trafik tumbuh 100x?

Question

IT Interview Practice · Accepted Answer

Skalakan secara bertahap: **read replica + caching untuk baca terlebih dahulu, lalu sharding (Vitess) untuk write** — dan tambahkan connection pooling sebelum hal lain, karena itu 10x termurah. Baca dan write menskala berbeda, jadi jangan meraih sharding di hari pertama.

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

## Langkah 0: connection pooling

Setiap koneksi MySQL memakan memori dan sebuah thread. Pada trafik 100x Anda akan menghabiskan `max_connections` jauh sebelum CPU. Sebuah pooler seperti **ProxySQL** atau **PgBouncer** memultipleks ribuan koneksi app ke beberapa ratus koneksi DB. Ini perubahan konfigurasi, bukan re-arsitektur — lakukan lebih dulu.

## Langkah 1: cache baca

Sebagian besar workload berat-baca (sering 90%+). Taruh **Redis** di depan untuk baris panas — profil pengguna, halaman produk. Cache hit tidak pernah menyentuh MySQL. Gunakan cache-aside: baca cache → miss → baca DB → isi cache. Ini saja bisa menyerap mayoritas dari 100x.

## Langkah 2: read replica

Tambahkan **async read replica** dan arahkan SELECT ke sana, write ke primary. Ini menskala baca secara horizontal: N replica ≈ N× kapasitas baca. Tangkapannya adalah **replication lag** — sebuah replica bisa tertinggal milidetik-hingga-detik, jadi read-your-own-writes butuh kehati-hatian (arahkan baca pengguna itu ke primary, atau baca dari cache).

## Langkah 3: shard write

Replica tidak membantu write — setiap write tetap mengenai primary tunggal. Ketika throughput write menjenuhkan satu mesin, **shard**. **Vitess** (dibangun di YouTube) duduk di depan MySQL dan melakukan sharding, query routing, dan online resharding tanpa menulis ulang app. Shard berdasarkan `user_id` agar sebagian besar query tetap single-shard.

## Perspektif wawancara

Pewawancara mengamati **urutan**: kandidat yang langsung men-shard menyingkap bahwa mereka tidak tahu replica/caching menyelesaikan skala baca jauh lebih murah. Baik: "tambahkan replica dan cache." Hebat: Anda memisahkan jalur baca dari jalur write, menyebut replication lag sebagai biaya replica, dan hanya memperkenalkan sharding ketika *write* — bukan baca — adalah bottleneck-nya.

**Jebakan umum:** "tambah saja read replica" saat bottleneck sebenarnya adalah throughput write. Replica membuat itu *lebih buruk* (lebih banyak beban replikasi pada primary).

## Trade-off & mode kegagalan

- **Replication lag:** baca basi; pin baca kritis ke primary atau gunakan semi-sync replication.
- **Cache stampede:** banyak miss mengenai DB sekaligus saat kedaluwarsa — gunakan lock atau TTL bertahap.
- **Kompleksitas sharding:** kehilangan join dan transaksi lintas-shard; bayar ini hanya setelah write memaksanya.
- **Failover:** matinya primary butuh promosi otomatis (Orchestrator); replica basi yang dipromosikan bisa kehilangan write terbaru.

Langkah 0: connection pooling

Langkah 1: cache baca

Langkah 2: read replica

Langkah 3: shard write

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait