لاکھوں کھلاڑیوں کے لیے ایک real-time leaderboard ڈیزائن کریں

Question

IT Interview Practice · Accepted Answer

**score سے keyed ایک Redis sorted set (ZSET) استعمال کریں: rank اور top-N O(log N) built-in operations بن جاتے ہیں، لہٰذا آپ کبھی فی request لاکھوں rows sort نہیں کرتے۔** ایک ZSET members کو خودکار طور پر score سے ordered رکھتا ہے؛ leaderboard بالکل یہی ہے۔

## فن تعمیر

```text
Game svc ──ZADD score──▶ Redis ZSET (sorted by score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "your rank" (around-me: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (durable source of truth)
```

## یہ کیسے کام کرتا ہے

- **ZADD** ایک کھلاڑی کے score کو O(log N) میں upsert کرتا ہے۔ Redis ایک **skip list** کے ذریعے ترتیب برقرار رکھتا ہے، لہٰذا کوئی re-sort ضروری نہیں۔
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` top 100 کو O(log N + 100) میں واپس کرتا ہے۔
- **آپ کا rank**: `ZREVRANK board user` 0-based position دیتا ہے؛ **around-me** `ZREVRANGE rank-5 rank+5` ہے — آپ کے قریب کے کھلاڑیوں کا slice۔
- **Durability**: Redis in-memory ہے۔ replay کے لیے **AOF** (append-only file) فعال کریں، اور scores کو true system of record کے طور پر asynchronously **Postgres** میں mirror کریں، تاکہ Redis کا نقصان قابلِ بحالی ہو۔

## لاکھوں users کے لیے sharding

ایک ZSET دسیوں ملین members ٹھیک رکھتا ہے (memory-bound، تقریباً 100MB فی 1M entries)۔ اس سے آگے، یا global scale کے لیے، **score range سے shard کریں** (0–1k، 1k–10k…) تاکہ ہر shard ایک متصل band ہو — ایک global top-N صرف top shard پڑھتا ہے۔ user hash سے sharding سے بچیں: random shards میں ranks کو دوبارہ جوڑنا مہنگا ہے۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا دیکھنا چاہتا ہے کہ آپ SQL پر `ORDER BY score LIMIT 100` (جو ہر hit پر re-sort کرتا ہے اور write load کے تحت مر جاتا ہے) کے بجائے **صحیح data structure کی طرف بڑھیں**۔ اچھے جواب ZSET کا نام لیتے ہیں؛ عمدہ جواب **around-me queries، ties، persistence، اور shard strategy** کا احاطہ کرتے ہیں۔ ایک کلاسک جال: بھول جانا کہ Redis volatile ہے اور اسے source of truth سمجھنا — ایک restart board مٹا دیتا ہے جب تک AOF/RDB یا ایک DB mirror موجود نہ ہو۔

## توازن اور ناکامی

- **Ties۔** برابر scores member کو lexicographically ترتیب دیتے ہیں، جو random لگتا ہے۔ score میں ایک tiebreaker encode کریں (مثلاً `score * 1e13 - timestamp`) تاکہ پہلے حاصل کرنے والے اوپر rank کریں۔
- **Hot key۔** ایک واحد global ZSET ایک shard پر ایک key ہے — ایک write hotspot۔ `ZADD`s کو buffer/batch کریں، یا load پھیلانے کے لیے time-bucketed boards (daily/weekly) استعمال کریں۔
- **مطابقت۔** Reads async DB mirror سے سیکنڈوں پیچھے ہو سکتے ہیں — leaderboards کے لیے ٹھیک، payouts کے لیے نہیں؛ انعامات دینے سے پہلے Postgres سے reconcile کریں۔
- **Memory لاگت۔** لاکھوں members حقیقی RAM خرچ کرتے ہیں؛ seasonal boards کو TTLs سے expire کریں۔
- **کب نہیں:** ہر منٹ refresh ہونے والا چند ہزار کا leaderboard ایک cached SQL query کے طور پر ٹھیک ہے — Redis ZSET تب چمکتا ہے جب writes مستقل ہوں اور rank فوری ہونا ضروری ہو۔

فن تعمیر

یہ کیسے کام کرتا ہے

لاکھوں users کے لیے sharding

انٹرویو کا نقطۂ نظر

توازن اور ناکامی

متعلقہ سوالات