તમે 1 અબજ યુઝર્સ માટે database કેવી રીતે shard કરશો?

Question

IT Interview Practice · Accepted Answer

એવા key વડે shard કરો જે **લગભગ દરેક query માં હાજર હોય અને load ને સમાન રીતે ફેલાવે** — સામાન્ય રીતે hashed `user_id` — પછી પહેલા દિવસથી resharding અને cross-shard queries માટે plan કરો. 1B યુઝર્સ એક node પર fit કે perform નહીં થાય; તમે rows ને ઘણી databases પર split કરો છો અને દરેક 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 પસંદગી — undo કરવો મુશ્કેલ નિર્ણય

**high cardinality, even distribution, અને મોટાભાગની queries માં હાજર** હોય તેવો key પસંદ કરો. `user_id` સામાન્ય રીતે જીતે છે: user-scoped queries ("મારી profile, મારા orders") બરાબર એક shard પર hit કરે છે. ખરાબ key (દા.ત. `country`) hotspots બનાવે છે — એક shard આખા India ને ધરાવે છે જ્યારે બીજો idle બેસે છે.

## Hash vs 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 પર land થાય).
- સામાન્ય જવાબ: **even load માટે hash**, એક **lookup/directory table** સાથે જેથી તમે બધું rehash કર્યા વગર ranges move કરી શકો.

## Resharding — જરૂર પડે તે પહેલાં plan કરો

`% N` એ trap છે: એક 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 વડે keyed ન હોય તે કંઈપણ પીડાદાયક છે: એક global "top posts" query દરેક shard પર fan out કરે અને merge કરે. **denormalizing** કરીને અથવા cross-cutting reads માટે અલગ index/search store (Elasticsearch) રાખીને mitigate કરો.

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

ઇન્ટરવ્યૂઅર્સ probe કરે છે કે તમે સમજો છો કે shard-key પસંદગી **semi-permanent** છે અને શું તમે **resharding અને cross-shard joins** વિશે વિચાર્યું છે — બે વસ્તુઓ જે production માં કરડે છે. Good: "user_id વડે shard કરો." Great: તમે consistent hashing, hot-shard mitigation, અને એ હકીકત ઉઠાવો છો કે shards પર distributed transactions સંપૂર્ણપણે ટાળવા શ્રેષ્ઠ છે.

**સામાન્ય trap:** fixed N સાથે `hash % N` — તે ભવિષ્યની growth ને full data migration બનાવે છે.

## Trade-offs અને failure modes

- **Lost cross-shard ACID:** shards પર સસ્તા joins/transactions નથી; sagas વાપરો અથવા denormalize કરો.
- **Hot shard:** એક viral user; sub-shard કરો અથવા તે entity ને cache કરો.
- **Rebalancing risk:** live migration cutover પહેલાં double-write અને verify કરવું જ પડે.
- **Operational cost:** N shards × replicas = monitor, back up, અને fail over કરવા માટે ઘણી databases.

Shard key પસંદગી — undo કરવો મુશ્કેલ નિર્ણય

Hash vs range

Resharding — જરૂર પડે તે પહેલાં plan કરો

Cross-shard queries

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

Trade-offs અને failure modes

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