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 માટે આગળ **Redis** મૂકો — user profiles, product pages. cache hit ક્યારેય MySQL ને સ્પર્શતું નથી. cache-aside વાપરો: cache વાંચો → miss → 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 મિલિસેકન્ડ્સ-થી-સેકન્ડ્સ પાછળ હોઈ શકે, તેથી read-your-own-writes ને કાળજી જોઈએ (તે user ના reads primary પર route કરો, અથવા cache માંથી વાંચો).

## Step 3: writes shard કરો

Replicas writes માં મદદ કરતા નથી — દરેક write હજુ એક જ 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 ને ઘણું સસ્તું ઉકેલે છે. Good: "replicas અને cache ઉમેરો." Great: તમે read path ને write path થી અલગ કરો છો, replicas ના cost તરીકે replication lag નું નામ આપો છો, અને માત્ર ત્યારે sharding રજૂ કરો છો જ્યારે *writes* — reads નહીં — bottleneck હોય.

**સામાન્ય trap:** "just add read replicas" જ્યારે વાસ્તવિક bottleneck write throughput હોય. Replicas તેને *ખરાબ* કરે છે (primary પર વધુ replication load).

## Trade-offs અને failure modes

- **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 તેને force કરે.
- **Failover:** primary death ને automated promotion (Orchestrator) જોઈએ; stale promoted replica તાજેતરની writes ગુમાવી શકે.

Step 0: connection pooling

Step 1: reads cache કરો

Step 2: read replicas

Step 3: writes shard કરો

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

સંબંધિત પ્રશ્નો