जब 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 बदलाव है, 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 → populate cache। यह अकेले 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 को सावधानी चाहिए (उस यूज़र के reads primary पर route करें, या cache से पढ़ें)।

## Step 3: writes shard करें

Replicas writes में मदद नहीं करतीं — हर write अब भी अकेले primary पर लगता है। जब write throughput एक box को saturate करे, **shard** करें। **Vitess** (YouTube में बना) MySQL के सामने बैठता है और app को फिर से लिखे बिना sharding, query routing, और online resharding करता है। `user_id` से shard करें ताकि अधिकांश queries single-shard रहें।

## इंटरव्यू का नज़रिया

Interviewers **क्रम** देखते हैं: जो 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)।

## ट्रेड-ऑफ़ और failure modes

- **Replication lag:** stale reads; critical reads primary पर pin करें या semi-sync replication इस्तेमाल करें।
- **Cache stampede:** expiry पर कई misses एक साथ DB पर लगते हैं — 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 करें

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure modes

संबंधित प्रश्न