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 लागतो. 100x 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 वापरा: read cache → miss → read DB → cache populate करा. हे एकटेच 100x च्या बहुतांश भाग शोषून घेऊ शकते.

## पायरी 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 मधून वाचा).

## पायरी 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 राहतात.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारे **क्रमाकडे** पाहतात: जे लगेच shard करतात ते दाखवतात की replicas/caching read scaling खूप स्वस्तात सोडवतात हे त्यांना माहीत नाही. चांगले: "replicas आणि cache जोडा." उत्तम: तुम्ही read path ला write path पासून वेगळे करता, replication lag ला replicas ची किंमत म्हणून नाव देता, आणि फक्त *writes* — reads नव्हे — bottleneck असतील तेव्हाच sharding आणता.

**सामान्य सापळा:** जेव्हा खरा bottleneck write throughput असतो तेव्हा "फक्त 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 भाग पाडतील तेव्हाच ही किंमत मोजा.
- **Failover:** primary मृत्यूला automated promotion (Orchestrator) लागते; एक stale promoted replica अलीकडील writes गमावू शकते.

पायरी 0: connection pooling

पायरी 1: reads cache करा

पायरी 2: read replicas

पायरी 3: writes shard करा

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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