लाखों players के लिए एक 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** एक player का score O(log N) में upsert करता है। Redis एक **skip list** के ज़रिए order बनाए रखता है, इसलिए 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` है — आपके पास के players का slice।
- **Durability**: Redis in-memory है। replay के लिए **AOF** (append-only file) सक्षम करें, और scores को true system of record के रूप में asynchronously **Postgres** में mirror करें, ताकि Redis का loss recoverable हो।

## लाखों users के लिए sharding

एक ZSET करोड़ों members ठीक रखता है (memory-bound, 1M entries के लिए ~100MB)। उससे आगे, या global scale के लिए, **score range से shard करें** (0–1k, 1k–10k…) ताकि हर shard एक contiguous band हो — एक global top-N केवल top shard पढ़ता है। user hash से sharding टालें: random shards में ranks फिर से जोड़ना महंगा है।

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

Interviewer आपको SQL पर `ORDER BY score LIMIT 100` के बजाय **सही data structure की ओर बढ़ते** देखना चाहता है (जो हर hit पर re-sort करता है और write load में मर जाता है)। अच्छे जवाब ZSET नाम लेते हैं; बढ़िया जवाब **around-me queries, ties, persistence, और shard strategy** cover करते हैं। एक क्लासिक जाल: भूल जाना कि Redis volatile है और इसे source of truth मानना — AOF/RDB या एक DB mirror न होने पर एक restart board मिटा देता है।

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

- **Ties.** समान scores member द्वारा lexicographically order होते हैं, जो random दिखता है। score में एक tiebreaker encode करें (जैसे `score * 1e13 - timestamp`) ताकि पहले achieve करने वाले ऊपर rank हों।
- **Hot key.** एक अकेला global ZSET एक shard पर एक key है — एक write hotspot। `ZADD`s को buffer/batch करें, या load फैलाने के लिए time-bucketed boards (daily/weekly) इस्तेमाल करें।
- **Consistency.** Reads async DB mirror से सेकंडों पीछे हो सकते हैं — leaderboards के लिए ठीक, payouts के लिए नहीं; prizes देने से पहले Postgres से reconcile करें।
- **Memory cost.** लाखों members वास्तविक RAM खर्च करते हैं; seasonal boards को TTLs से expire करें।
- **कब नहीं:** हर minute refresh होने वाला कुछ हज़ार का leaderboard एक cached SQL query के रूप में ठीक है — Redis ZSET तब चमकता है जब writes लगातार हों और rank तुरंत होना चाहिए।

आर्किटेक्चर

यह कैसे काम करता है

लाखों users के लिए sharding

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

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

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