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 చేస్తుంది. ఇది rearchitecture కాదు, ఒక config మార్పు — దీన్ని మొదట చేయండి.

## Step 1: reads ను cache చేయండి

చాలా workloads read-heavy (తరచుగా 90%+). hot rows కోసం ముందు **Redis** ను ఉంచండి — user profiles, product pages. ఒక 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-to-seconds వెనుకబడవచ్చు, కాబట్టి read-your-own-writes కి జాగ్రత్త అవసరం (ఆ user యొక్క reads ను primary కి route చేయండి, లేదా cache నుండి read చేయండి).

## Step 3: writes ను shard చేయండి

Replicas writes కి సహాయపడవు — ప్రతి write ఇంకా ఒక్క primary ను తాకుతుంది. write throughput ఒక box ను saturate చేసినప్పుడు, **shard** చేయండి. **Vitess** (YouTube లో నిర్మించబడింది) MySQL ముందు కూర్చుని app ను తిరిగి వ్రాయకుండా sharding, query routing, మరియు online resharding చేస్తుంది. చాలా queries single-shard గా ఉండేలా `user_id` ద్వారా shard చేయండి.

## ఇంటర్వ్యూ దృక్కోణం

ఇంటర్వ్యూయర్‌లు **ordering** కోసం చూస్తారు: వెంటనే shard చేసే candidates replicas/caching read scaling ను చాలా చవకగా పరిష్కరిస్తాయని తెలియదని బహిర్గతం చేస్తారు. మంచిది: "replicas మరియు cache జోడించండి." గొప్పది: మీరు read path ను write path నుండి వేరు చేసి, replication lag ను replicas యొక్క cost గా పేర్కొని, *writes* — reads కాదు — bottleneck అయినప్పుడు మాత్రమే sharding ను ప్రవేశపెడతారు.

**సాధారణ ఉచ్చు:** అసలు bottleneck write throughput అయినప్పుడు "just add read replicas". Replicas దాన్ని *అధ్వాన్నం* చేస్తాయి (primary పై ఎక్కువ replication load).

## ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

- **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 force చేసినప్పుడే దీన్ని pay చేయండి.
- **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 చేయండి

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు