traffic 100x बढ्दा MySQL कसरी scale गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

चरणबद्ध रूपमा scale गर्नुहोस्: **पहिले read का लागि read replica + caching, अनि write का लागि sharding (Vitess)** — र अरू केही अघि connection pooling थप्नुहोस्, किनकि यो सबैभन्दा सस्तो 10x हो। read र write फरक तरिकाले 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 खर्च गर्छ। 100x traffic मा तपाईं CPU भन्दा धेरै पहिले `max_connections` सिध्याउनुहुन्छ। **ProxySQL** वा **PgBouncer** जस्तो pooler ले हजारौं app connection लाई केही सयवटा DB connection मा multiplex गर्छ। यो rearchitecture होइन, config परिवर्तन हो — यो पहिले गर्नुहोस्।

## चरण 1: read cache गर्नुहोस्

अधिकांश workload read-heavy (प्रायः 90%+) हुन्छन्। hot row — user profile, product page — का लागि अगाडि **Redis** राख्नुहोस्। cache hit ले कहिल्यै MySQL छुँदैन। cache-aside प्रयोग गर्नुहोस्: cache पढ → miss → DB पढ → cache populate गर। यो एक्लैले 100x को अधिकांश सोस्न सक्छ।

## चरण 2: read replica

**async read replica** थप्नुहोस् र SELECT लाई तिनमा, write लाई primary मा route गर्नुहोस्। यसले read horizontally scale गर्छ: N replica ≈ N× read क्षमता। समस्या **replication lag** हो — replica millisecond-देखि-second पछि हुन सक्छ, त्यसैले read-your-own-writes लाई ध्यान चाहिन्छ (त्यो प्रयोगकर्ताको read primary मा route गर्नुहोस्, वा cache बाट पढ्नुहोस्)।

## चरण 3: write shard गर्नुहोस्

replica ले write मा मद्दत गर्दैन — हरेक write अझै एउटै primary हान्छ। एउटा box मा write throughput saturate हुँदा, **shard** गर्नुहोस्। **Vitess** (YouTube मा बनेको) MySQL अगाडि बस्छ र app पुनर्लेखन नगरी sharding, query routing, र online resharding गर्छ। `user_id` अनुसार shard गर्नुहोस् ताकि अधिकांश query single-shard रहून्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारहरूले **क्रम** हेर्छन्: तुरुन्तै shard गर्ने candidate ले replica/caching ले read scaling धेरै सस्तोमा हल गर्छ भनेर जान्दैनन् भनी देखाउँछन्। राम्रो: "replica र cache थप।" उत्कृष्ट: तपाईं read path लाई write path बाट छुट्याउनुहुन्छ, replication lag लाई replica को लागत भनेर नाम दिनुहुन्छ, र *write* — read होइन — bottleneck हुँदा मात्र sharding ल्याउनुहुन्छ।

**साधारण जाल:** वास्तविक bottleneck write throughput हुँदा "बस read replica थप।" replica ले त्यसलाई *अझ नराम्रो* बनाउँछ (primary मा अझ बढी replication load)।

## ट्रेड-अफ र failure mode

- **Replication lag:** stale read; critical read primary मा pin गर्नुहोस् वा semi-sync replication प्रयोग गर्नुहोस्।
- **Cache stampede:** expiry मा धेरै miss एकैचोटि DB हान्छन् — lock वा staggered TTL प्रयोग गर्नुहोस्।
- **Sharding जटिलता:** cross-shard join र transaction गुमाउँछ; write ले बाध्य पारेपछि मात्र यो मूल्य तिर्नुहोस्।
- **Failover:** primary मरे automated promotion (Orchestrator) चाहिन्छ; stale promoted replica ले भर्खरका write गुमाउन सक्छ।

चरण 0: connection pooling

चरण 1: read cache गर्नुहोस्

चरण 2: read replica

चरण 3: write shard गर्नुहोस्

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू