ਜਦੋਂ traffic 100x ਵਧੇ, ਤਾਂ ਤੁਸੀਂ MySQL ਨੂੰ ਕਿਵੇਂ scale ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

ਪੜਾਵਾਂ ਵਿੱਚ scale ਕਰੋ: **ਪਹਿਲਾਂ reads ਲਈ read replicas + caching, ਫਿਰ writes ਲਈ sharding (Vitess)** — ਅਤੇ ਬਾਕੀ ਸਭ ਤੋਂ ਪਹਿਲਾਂ connection pooling ਜੋੜੋ, ਕਿਉਂਕਿ ਇਹ ਸਭ ਤੋਂ ਸਸਤਾ 10x ਹੈ। Reads ਅਤੇ writes ਵੱਖ-ਵੱਖ ਢੰਗ ਨਾਲ scale ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਪਹਿਲੇ ਦਿਨ 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
```

## Step 0: connection pooling

ਹਰ MySQL connection ਨੂੰ memory ਅਤੇ ਇੱਕ thread ਦੀ ਕੀਮਤ ਪੈਂਦੀ ਹੈ। 100x traffic ਉੱਤੇ ਤੁਸੀਂ CPU ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ `max_connections` ਖਤਮ ਕਰ ਦਿਓਗੇ। **ProxySQL** ਜਾਂ **PgBouncer** ਵਰਗਾ ਇੱਕ pooler ਹਜ਼ਾਰਾਂ app connections ਨੂੰ ਕੁਝ ਸੌ DB connections ਉੱਤੇ multiplex ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ config change ਹੈ, rearchitecture ਨਹੀਂ — ਇਸਨੂੰ ਪਹਿਲਾਂ ਕਰੋ।

## Step 1: reads ਨੂੰ cache ਕਰੋ

ਜ਼ਿਆਦਾਤਰ workloads read-heavy ਹੁੰਦੇ ਹਨ (ਅਕਸਰ 90%+)। hot rows — user profiles, product pages — ਲਈ ਸਾਹਮਣੇ **Redis** ਲਾਓ। ਇੱਕ cache hit ਕਦੇ MySQL ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ। cache-aside ਵਰਤੋ: read cache → miss → read DB → cache populate ਕਰੋ। ਇਹ ਇਕੱਲਾ ਹੀ 100x ਦਾ ਬਹੁਤ ਹਿੱਸਾ ਜਜ਼ਬ ਕਰ ਸਕਦਾ ਹੈ।

## Step 2: read replicas

**async read replicas** ਜੋੜੋ ਅਤੇ SELECTs ਨੂੰ ਉਹਨਾਂ ਵੱਲ, writes ਨੂੰ primary ਵੱਲ route ਕਰੋ। ਇਹ reads ਨੂੰ horizontally scale ਕਰਦਾ ਹੈ: N replicas ≈ N× read capacity। ਪੇਚ ਹੈ **replication lag** — ਇੱਕ replica milliseconds-ਤੋਂ-seconds ਪਿੱਛੇ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ read-your-own-writes ਨੂੰ ਧਿਆਨ ਚਾਹੀਦਾ ਹੈ (ਓਸ user ਦੇ reads ਨੂੰ primary ਵੱਲ route ਕਰੋ, ਜਾਂ cache ਤੋਂ ਪੜ੍ਹੋ)।

## Step 3: writes ਨੂੰ shard ਕਰੋ

Replicas writes ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੇ — ਹਰ write ਅਜੇ ਵੀ single primary ਨੂੰ hit ਕਰਦਾ ਹੈ। ਜਦੋਂ write throughput ਇੱਕ box ਨੂੰ saturate ਕਰ ਦੇਵੇ, ਤਾਂ **shard** ਕਰੋ। **Vitess** (YouTube ਵਿੱਚ ਬਣਾਇਆ) MySQL ਦੇ ਸਾਹਮਣੇ ਬੈਠਦਾ ਹੈ ਅਤੇ app ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ ਬਿਨਾਂ sharding, query routing, ਅਤੇ online resharding ਕਰਦਾ ਹੈ। `user_id` ਨਾਲ shard ਕਰੋ ਤਾਂ ਜੋ ਜ਼ਿਆਦਾਤਰ queries single-shard ਰਹਿਣ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ **ordering** ਦੇਖਦੇ ਹਨ: ਜੋ candidates ਤੁਰੰਤ shard ਕਰਦੇ ਹਨ ਉਹ ਦੱਸ ਦਿੰਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ replicas/caching read scaling ਨੂੰ ਕਿਤੇ ਸਸਤੇ ਵਿੱਚ ਹੱਲ ਕਰਦੇ ਹਨ। ਵਧੀਆ: "replicas ਅਤੇ ਇੱਕ cache ਜੋੜੋ।" ਸ਼ਾਨਦਾਰ: ਤੁਸੀਂ read path ਨੂੰ write path ਤੋਂ ਵੱਖ ਕਰਦੇ ਹੋ, replicas ਦੀ ਕੀਮਤ ਵਜੋਂ replication lag ਦਾ ਨਾਂ ਲੈਂਦੇ ਹੋ, ਅਤੇ sharding ਸਿਰਫ਼ ਤਦ ਲਿਆਉਂਦੇ ਹੋ ਜਦੋਂ *writes* — reads ਨਹੀਂ — bottleneck ਹੋਣ।

**ਆਮ ਫੰਦਾ:** "ਬਸ read replicas ਜੋੜੋ" ਜਦੋਂ ਅਸਲ bottleneck write throughput ਹੈ। Replicas ਇਸਨੂੰ *ਹੋਰ ਮਾੜਾ* ਬਣਾਉਂਦੇ ਹਨ (primary ਉੱਤੇ ਵੱਧ replication load)।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **Replication lag:** stale reads; critical reads ਨੂੰ primary ਨਾਲ pin ਕਰੋ ਜਾਂ semi-sync replication ਵਰਤੋ।
- **Cache stampede:** expiry ਉੱਤੇ ਕਈ misses ਇੱਕੋ ਵਾਰ DB ਨੂੰ hit ਕਰਦੇ ਹਨ — locks ਜਾਂ staggered TTLs ਵਰਤੋ।
- **Sharding complexity:** cross-shard joins ਅਤੇ transactions ਗੁਆ ਦਿੰਦੀ ਹੈ; ਇਹ ਕੀਮਤ ਸਿਰਫ਼ ਤਦ ਚੁਕਾਓ ਜਦੋਂ writes ਮਜਬੂਰ ਕਰਨ।
- **Failover:** primary ਦੀ ਮੌਤ ਨੂੰ automated promotion (Orchestrator) ਚਾਹੀਦੀ ਹੈ; ਇੱਕ stale promoted replica ਹਾਲੀਆ writes ਗੁਆ ਸਕਦੀ ਹੈ।

Step 0: connection pooling

Step 1: reads ਨੂੰ cache ਕਰੋ

Step 2: read replicas

Step 3: writes ਨੂੰ shard ਕਰੋ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ