جب traffic 100 گنا بڑھے تو آپ 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
```

## قدم 0: connection pooling

ہر MySQL connection memory اور ایک thread خرچ کرتا ہے۔ 100 گنا traffic پر آپ CPU سے بہت پہلے `max_connections` ختم کر دیں گے۔ **ProxySQL** یا **PgBouncer** جیسا ایک pooler ہزاروں app connections کو چند سو DB connections پر multiplex کرتا ہے۔ یہ ایک config تبدیلی ہے، rearchitecture نہیں — اسے پہلے کریں۔

## قدم 1: reads کو cache کریں

زیادہ تر workloads read-heavy ہوتے ہیں (اکثر 90%+)۔ hot rows کے لیے آگے **Redis** رکھیں — user profiles، product pages۔ ایک cache hit کبھی MySQL کو نہیں چھوتا۔ cache-aside استعمال کریں: cache پڑھو → miss → DB پڑھو → cache آباد کرو۔ صرف یہی 100x کی اکثریت جذب کر سکتا ہے۔

## قدم 2: read replicas

**async read replicas** شامل کریں اور SELECTs کو ان کی طرف، writes کو primary کی طرف route کریں۔ یہ reads کو horizontally scale کرتا ہے: N replicas ≈ N× read capacity۔ رکاوٹ **replication lag** ہے — ایک replica milliseconds سے سیکنڈوں تک پیچھے ہو سکتا ہے، لہٰذا read-your-own-writes کو احتیاط چاہیے (اُس صارف کے reads primary کی طرف route کریں، یا cache سے پڑھیں)۔

## قدم 3: writes کو shard کریں

replicas writes میں مدد نہیں کرتے — ہر write اب بھی واحد primary کو hit کرتی ہے۔ جب write throughput ایک box کو saturate کر دے، **shard کریں**۔ **Vitess** (YouTube پر بنایا گیا) MySQL کے آگے بیٹھتا ہے اور sharding، query routing، اور online resharding کرتا ہے بغیر app دوبارہ لکھے۔ `user_id` سے shard کریں تاکہ زیادہ تر queries single-shard رہیں۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والے **ترتیب** دیکھتے ہیں: جو امیدوار فوراً shard کرتے ہیں وہ ظاہر کرتے ہیں کہ انہیں معلوم نہیں کہ replicas/caching read scaling کہیں زیادہ سستے میں حل کرتے ہیں۔ اچھا: "replicas اور ایک cache شامل کرو۔" عمدہ: آپ read path کو write path سے الگ کرتے ہیں، replication lag کو replicas کی لاگت کے طور پر نام دیتے ہیں، اور 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 پیچیدگی:** cross-shard joins اور transactions کھو دیتی ہے؛ یہ صرف تب ادا کریں جب writes مجبور کریں۔
- **Failover:** primary کی موت کو خودکار promotion چاہیے (Orchestrator)؛ ایک stale promoted replica حالیہ writes کھو سکتا ہے۔

قدم 0: connection pooling

قدم 1: reads کو cache کریں

قدم 2: read replicas

قدم 3: writes کو shard کریں

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات