आप 1 अरब यूज़र्स के लिए एक database कैसे shard करेंगे?

Question

IT Interview Practice · Accepted Answer

एक ऐसी key से shard करें जो **लगभग हर query में मौजूद हो और load को समान रूप से फैलाए** — आमतौर पर एक hashed `user_id` — फिर पहले दिन से resharding और cross-shard queries की योजना बनाएं। 1 अरब यूज़र्स एक node पर न समाएंगे न perform करेंगे; आप rows को कई databases में बांटते हैं और हर query को उस shard पर route करते हैं जो उसका मालिक है।

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Shard key का चुनाव — वह निर्णय जिसे पलटना कठिन है

**high cardinality, समान distribution, और अधिकांश queries में मौजूद** एक key चुनें। `user_id` आमतौर पर जीतता है: user-scoped queries ("मेरी profile, मेरे orders") ठीक एक shard पर लगती हैं। एक खराब key (जैसे `country`) hotspots बनाता है — एक shard पूरे भारत को रखता है जबकि दूसरा खाली बैठा रहता है।

## Hash बनाम range

- **Hash sharding** (`shard = hash(user_id) % N`): समान रूप से distribute करता है, hotspots खत्म करता है — पर range queries ("पिछले हफ़्ते बने users") को सभी shards में scatter-gather करना होता है।
- **Range sharding** (`user_id 0–1M → shard 0`): ranges को local रखता है और resharding आसान बनाता है, पर hotspots का जोखिम (सबसे नए users सब अंतिम shard पर लगते हैं)।
- आम जवाब: **समान load के लिए hash**, एक **lookup/directory table** के साथ ताकि आप बिना सब कुछ rehash किए ranges move कर सकें।

## Resharding — ज़रूरत से पहले योजना बनाएं

`% N` एक जाल है: एक shard जोड़ने से लगभग हर key remap हो जाती है। **consistent hashing** या **virtual buckets** (keys → 4096 logical buckets → physical shards map करें) इस्तेमाल करें। तब एक shard को split करने से buckets move होते हैं, पूरा keyspace नहीं। **Vitess** (YouTube/Slack द्वारा इस्तेमाल) जैसे tools cutover के साथ live resharding automate करते हैं।

## Cross-shard queries

shard key से key न होने वाली कोई भी चीज़ दर्दनाक है: एक global "top posts" query हर shard में fan out करती है और merge करती है। **denormalizing** या cross-cutting reads के लिए एक अलग index/search store (Elasticsearch) रखकर कम करें।

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

Interviewers परखते हैं कि क्या आप समझते हैं shard-key चुनाव **अर्ध-स्थायी** है और क्या आपने **resharding और cross-shard joins** के बारे में सोचा है — production में जो दो चीज़ें काटती हैं। अच्छा: "user_id से shard करें।" बढ़िया: आप consistent hashing, hot-shard mitigation, और यह तथ्य उठाते हैं कि shards में distributed transactions पूरी तरह टालना सबसे अच्छा है।

**आम जाल:** एक fixed N के साथ `hash % N` — यह भविष्य की growth को एक पूर्ण data migration बना देता है।

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

- **खोया cross-shard ACID:** shards में कोई सस्ते joins/transactions नहीं; sagas इस्तेमाल करें या denormalize करें।
- **Hot shard:** एक viral user; उस entity को sub-shard या cache करें।
- **Rebalancing जोखिम:** live migration को cutover से पहले double-write और verify करना चाहिए।
- **Operational cost:** N shards × replicas = monitor, back up, और fail over करने के लिए कई databases।

Shard key का चुनाव — वह निर्णय जिसे पलटना कठिन है

Hash बनाम range

Resharding — ज़रूरत से पहले योजना बनाएं

Cross-shard queries

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

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

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