लाखौं खेलाडीका लागि real-time leaderboard डिजाइन गर्नुहोस्

Question

IT Interview Practice · Accepted Answer

**score अनुसार key गरिएको Redis sorted set (ZSET) प्रयोग गर्नुहोस्: rank र top-N built-in O(log N) operation बन्छन्, त्यसैले तपाईं कहिल्यै प्रति request लाखौं row sort गर्नुहुन्न।** ZSET ले member हरूलाई स्वतः score अनुसार क्रमबद्ध राख्छ; 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** मार्फत क्रम राख्छ, त्यसैले पुनः-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) सक्षम गर्नुहोस्, र सत्यको वास्तविक system-of-record को रूपमा score लाई asynchronous रूपमा **Postgres** मा mirror गर्नुहोस्, ताकि Redis हानि recoverable होस्।

## लाखौं user का लागि sharding

एउटा ZSET ले करोडौं member ठीकसँग राख्छ (memory-bound, 1M entry का लागि ~100MB)। त्यसभन्दा माथि, वा global scale का लागि, **score range अनुसार shard** (0–1k, 1k–10k…) गर्नुहोस् ताकि प्रत्येक shard एउटा contiguous band होस् — global top-N ले top shard मात्र पढ्छ। user hash अनुसार sharding बच्नुहोस्: random shard बीच rank पुनः-जोड्नु महँगो हुन्छ।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले SQL मा `ORDER BY score LIMIT 100` (जसले हरेक hit मा पुनः-sort गर्छ र write load मा मर्छ) को सट्टा **सही data structure** तिर पुग्नुहुन्छ कि हेर्न चाहन्छन्। राम्रो उत्तरले ZSET नाम दिन्छ; उत्कृष्टले **around-me query, tie, persistence, र shard strategy** समेट्छ। एउटा classic जाल: Redis अस्थिर छ भनेर बिर्सनु र यसलाई सत्यको स्रोत मान्नु — AOF/RDB वा DB mirror नभए restart ले board मेटाउँछ।

## ट्रेड-अफ र failure

- **Tie.** बराबर score member अनुसार lexicographically क्रमबद्ध हुन्छ, जुन random देखिन्छ। score मा tiebreaker encode गर्नुहोस् (जस्तै `score * 1e13 - timestamp`) ताकि पहिले हासिल गर्नेले माथि rank पाओस्।
- **Hot key.** एउटै global ZSET एउटा shard मा एउटा key हो — write hotspot। `ZADD` लाई buffer/batch गर्नुहोस्, वा load फैलाउन time-bucketed board (दैनिक/साप्ताहिक) प्रयोग गर्नुहोस्।
- **Consistency.** read हरू async DB mirror भन्दा second हरू पछि पर्न सक्छन् — leaderboard का लागि ठीक, payout का लागि होइन; prize दिनुअघि Postgres बाट reconcile गर्नुहोस्।
- **Memory लागत.** लाखौं member ले वास्तविक RAM खर्च गर्छन्; seasonal board लाई TTL सँग expire गर्नुहोस्।
- **कहिले नगर्ने:** हरेक मिनेट refresh हुने केही हजारको leaderboard cache गरिएको SQL query को रूपमा ठीक छ — Redis ZSET write निरन्तर हुँदा र rank तुरुन्तै हुनुपर्दा चम्किन्छ।

आर्किटेक्चर

कसरी काम गर्छ

लाखौं user का लागि sharding

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure

सम्बन्धित प्रश्नहरू