लाखो 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) मध्ये return करते.
- **तुमची 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 asynchronously **Postgres** ला खरे system of record म्हणून mirror करा, जेणेकरून Redis तोटा recoverable असतो.

## लाखो युजरसाठी sharding

एक ZSET कोट्यवधी members ठीक धरते (memory-bound, 1M entries साठी ~100MB). त्यापलीकडे, किंवा 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** कव्हर करतात. एक classic सापळा: Redis volatile आहे हे विसरणे आणि त्याला source of truth मानणे — AOF/RDB किंवा DB mirror नसेल तर restart board पुसतो.

## तडजोडी आणि अपयश

- **Ties.** समान scores member lexicographically ने order होतात, जे 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) वापरा.
- **Consistency.** Reads async DB mirror च्या मागे सेकंदांनी राहू शकतात — leaderboards साठी ठीक, payouts साठी नाही; बक्षिसे देण्याआधी Postgres मधून reconcile करा.
- **Memory cost.** लाखो members ना खरी RAM लागते; seasonal boards TTLs सह expire करा.
- **कधी नको:** दर मिनिटाला refresh होणारा काही हजारांचा leaderboard एक cached SQL query म्हणून ठीक आहे — writes सतत असतील आणि rank तत्काळ लागेल तेव्हा Redis ZSET चमकते.

आर्किटेक्चर

कसे कार्य करते

लाखो युजरसाठी sharding

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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